Derek Chiang's blog

Frame vs Tempo — Two clashing philosophies of native AA

The planning for Ethereum’s Hegota hard fork is currently underway, and the hottest topic within the core devs community right now is native AA. In the past month alone, no less than 4 new EIPs for native AA have been proposed, including EIP-8141 aka “Frame Transactions” which was formally proposed as a headliner for Hegota.

Despite the momentum, the future of native AA is very much in doubt, because there’s heated debate among the client teams as to whether Frame Transactions is actually a good idea and whether some other AA proposals — such as “Tempo Transactions” — might be a better choice.

In this post, I will explain:

Two competing philosophies

In the history of account abstraction research, there has always been two competing philosophies, and Frame Transactions and Tempo Transactions are simply the latest iterations of them.

The two philosophies can be summarized as such:

Now let’s look at how Tempo Transactions and Frame Transactions exemplify these philosophies.

Tempo Transactions: Give users what they want

In the few years since ERC-4337 has been in production, it has been very clear (especially to those of us who have been selling AA solutions) what the most highly demanded AA features are. They are (in order from more to less demanded):

So the Tempo philosophy is simple: let’s just enshrine these features into the protocol. This is apparent by just looking at the structure of a Tempo transaction:

Notice the parts where it differs from a regular transaction:

Notice how simple everything is. You don’t need to be a PHD in account abstraction to use these features — you just put the right data into the transaction. The simplicity, both for developers and for users, is the greatest strength of Tempo-style AA proposals.

However, also notice how some features are missing compared to our AA wishlist, such as ERC20 gas payments, permissions, and multisig. To make these features work, you’d need to enshrine more things into the protocol; for example, the Tempo blockchain itself enshrines a “fee AMM” for converting between ERC20s and native gas tokens, thus enabling gas payments in ERC20s.

Since all AA features are enshrined into the protocol, a developer building for a use case outside of what Tempo Transactions were intended for have no choice but to wait for the protocol to enshrine more features, or resort to application-layer solutions (such as ERC-4337) and accept the higher latency, higher gas cost, and lower security that come with them. The lack of extensibility is therefore the biggest downside of the Tempo philosophy.

Frame Transactions: Let developers build what they want

To understand how Frame Transactions represent a fundamentally different philosophy, let’s again look at the transaction structure:

The most interesting thing about this structure is what’s missing: signatures. Whereas a Tempo transaction has two signature fields — sender_signature and fee_payer_signature — frame transactions have none. Wait, what? How do you authorize transactions without signatures?

The answer is that frame transactions seek to generalize transactions to its most abstract form — smart contracts processing data. To authorize a transaction, you simply pass the signature as data to a smart contract that authorizes transactions.

To allow smart contracts to authorize transactions, EIP-8141 introduces a new opcode APPROVE where a smart contract would call:

But what’s the point of all this, when you can just embed sender and payer signatures directly into the transaction like Tempo Transactions do? The point is that sender and gas payer logic can now be implemented with arbitrary code, enabling use cases not supported by Tempo Transactions, such as:

Frame Transactions are undoubtedly more powerful than Tempo Transactions, but they come at the cost of complexity: it’s no longer obvious what’s the best way to do any given thing. Since account logic is implemented with EVM code, any AA feature can be implemented in an infinite number of ways, since EVM code is infinitely flexible.

More concretely, the complexity can manifest in several layers:

In short, to pay for the power and flexibility of frames, the ecosystem must handle increased complexity across the Web3 stack.

Can we get the best of both worlds?

If you have read this far, you may be under the impression that we are stuck between two bad choices:

Neither of these choices seems good. What do?

Fortunately, the real world is not so binary; thanks to feedback from the community, and with some contributions from myself, the coauthors of Frame Transactions are currently working on a set of updates that would enable Frame transactions to maintain their flexibility while keeping the cost of adoption low. These updates include:

Again, none of these updates takes away from the flexibility of frames and how they can compose into arbitrarily advanced account logic. That’s how we get the best of worlds: offering sane defaults for the most common use cases, while providing composable primitives for developers to build for the more advanced use cases.

How you can help

Later this week, Ethereum client developers will be meeting to decide whether to implement Frame transactions for the Hegota upgrade. If you care about improving UX for Ethereum, now is the best time to get involved. Here are some ways you can help:

Ethereum is at its best when the community gets involved, and for an issue like native AA which affects EVERYONE, your input might just make the difference.

← About me