The new AA debate — 8130 vs Frame Transactions
A few months ago I published an article comparing Tempo Transactions and Frame Transactions (EIP-8141). Since then, the core devs community have largely rejected Tempo-style AA proposals for their rigidity, and embraced Frames for its flexibility.
Recently, Base released its AA proposal — EIP-8130 — and has formally submitted it for consideration for the L1. This has rekindled the AA debate, this time between 8130 and Frames, with notable voices supporting both sides.
At Ethlabs, we have been deeply engaging with coauthors of both proposals, in order to understand their view points and see if we can find common ground. In this article, I want to give an overview of the current state of the debate, present the arguments for both sides, and share my own thoughts on how the ACD should decide between these two proposals.
#Why L2s worry about Frames
L2s want to scale — to offer high TPS. However, frame transactions are hard to scale, because they are validated with EVM code, which takes an unknown (and possibly unbounded) amount of gas to execute. This is in contrast to regular transactions which can be validated by just checking a signature, with a known and bounded cost.
Furthermore, because the validation code can access any state, nodes must take care to re-validate transactions if the state they accessed changed. Nodes therefore must trace through the validation phase of a frame transaction, in order to identify the state it touched, which introduces additional performance penalties for high-performance L2s.
#Why L1 worries about 8130
To circumvent the issue above, 8130 maintains a whitelist (aka “canonical set”) of “authenticators” which are contracts that implement common signature schemes such as k1 and r1 (passkeys). Accounts register their authenticators in a “keystore” contract, so nodes can simply look up an account’s authenticator and know how much it’s going to cost to validate the transaction, and even optimize the validation with native code. Because authenticators simply validate signatures, they are “pure functions” that don’t access state, so once validated a transaction doesn’t need to be re-validated.
However, this scheme is a poor fit for the L1 because L1 wants to enable permissionless innovation — anyone should be free to develop their own accounts. This includes use cases such as multisig, PQ, private transactions, and other novel authentication schemes. Requiring constant hardforks to support new authentication schemes is a non-starter for the L1.
#How both specs have been evolving
In recent weeks, both specs have been evolving to address their shortcomings.
On the Frames side, thanks to feedback from L2s (mainly Base and Arbitrum), the coauthors have been working on a “pure function validation” scheme which would allow signatures to be verified by pure functions — contracts that don’t access any state. These pure functions resemble 8130 authenticators — they can be identified by addresses, have bounded cost, and can be optimized with native code. This would allow L2s to validate frame transactions with predictable and bounded cost.
On the 8130 side, the coauthors have added an “L1 profile” to the spec, allowing chains that adopt the L1 profile (such as Ethereum) to support “non-canonical authenticators” which are authenticators with arbitrary logic. Using such an authenticator would of course defeat many of the benefits of 8130, but it gives the L1 a path to support permissionless account implementations.
#The fundamental differences that remain
With Frames implementing 8130-style authenticators, and with 8130 supporting an L1 profile, the two specs are converging. But some fundamental differences still remain:
#Cross-chain portability
8130 has a complete story around cross-chain portability — 8130 accounts can work even on chains that don’t natively support 8130, in which case the 8130 transactions will be relayed through ERC-4337 bundlers and paymasters.
While the same can be done for 8141, the design has not been scoped out. This is an engineering gap, but not a fundamental one.
#Enshrined account vs pure AA
8130 is actually two specs in one — there’s the underlying idea of validating transactions via authenticators, and then there’s a full account standard on top with concepts such as policies (session keys), actors, locks, etc. In short, with 8130, all accounts will have similar structures, so it’s easier to build wallets and toolings around it, but evolving the accounts would be harder since it will require more hard forks.
On the other hand, 8141 focuses on AA itself — it only provides the primitives for building accounts. The protocol itself is unopinionated about the logic of the accounts. This opens up more room for account innovation and diversity, but also more possibilities for fragmentation, which are really two sides of the same coin.
#Structured vs unstructured validation
The most fundamental difference between 8141 and 8130 is how transactions are structured, or more precisely when validation must occur relative to execution.
In 8130, validation is structured — validation happens first, followed by execution. This is very natural and will simplify toolings built around it.
In 8141, validation is unstructured — validation can happen via any frame at any point during the transaction. This means you can technically execute the transaction first, then validate it. This opens up powerful use cases where an account doesn’t have ETH to begin with, but acquires ETH during execution, and finally pays gas with the ETH. For examples:
- Say you have an account with some memecoins but no ETH. You can send a transaction that swaps the memecoins to ETH during execution, then pay for the transaction (validate).
- Similarly, say you have an account with no ETH but has ETH in some DeFi protocol. Your transaction can execute first, pull the ETH from the DeFi protocol, then finally pay for the transaction (validate).
In short, unstructured validation opens up use cases for ETH-less accounts to pay for transactions with arbitrary logic.
However, unstructured validation comes with a caveat — they cannot be safely supported in the public mempool, since validation that depends on execution can be easily invalidated by a change of on-chain state. That’s why 8141 introduces additional mempool rules to constraint the validation structure. Therefore, in practice, use cases for unstructured validation such as described above must be supported via private mempools and builder APIs.
#What the decision comes down to
In short, I believe the choice between 8130 and 8141 comes down to this:
- If we prefer simplicity and less fragmentation, we should adopt an approach that looks like 8130.
- If we prefer extensibility and more diversity, we should adopt an approach that looks like 8141.
Note that I said “an approach that looks like 8130/8141” — I want to differentiate the approach from the EIP number, because any EIP may ends up adopting any approach, and we may even end up with a totally new EIP that synthesizes these approaches. My arguments are therefore for specific approaches, not specific EIP numbers.
Historically, Ethereum has been more aligned with the Frames philosophy — the protocol offers maximal flexibility, while the application layer innovates and competes. However, it’s worth asking if the account layer, which is fundamental to Ethereum UX, deserves more guidance and structure from the protocol itself.
#The path forward
At Ethlabs, we believe that when evolving fundamental EVM constructs such as the account, we must not optimize for the needs of the L1 alone, but rather take feedback from other stakeholders such as wallets and L2s. This is because we believe Ethereum benefits greatly from the network effects of the EVM, so we should aim to maintain a cohesive and compatible ecosystem, only deviating when it’s necessary for meeting the unique needs of L1 and L2s.
With regard to the current debate, I would recommend that the ACD takes one of the following approaches:
- If we as a community believe that simplicity is more important than extensibility, I recommend that we adopt 8130’s keystore-based validation scheme, but strip out its enshrined account into a separate ERC. That way, Ethereum and L2s benefit from the simplicity of structured validation, while giving room for new types of accounts to develop.
- If we as a community believe that extensibility is more important than simplicity, I recommend that we continue building on frames, but we must finish the “pure functions” workstream (or a similar idea) that would enable L2s to support frames without sacrificing validation performance, and ideally work out a cross-chain portability scheme similar to 8130’s.
The AA debate is stretching Ethereum’s decentralized governance model to its limits, but I believe we are on track to proving once again that the community can unite and ship ambitious updates that make Ethereum better than ever. I and my colleagues from Ethlabs will be joining the AA breakouts and ACDE this week to take part in this conversation; I hope to see you all there!