Thread by @lightclients

The design space for protocol upgrades that improve the user experience on Ethereum is large, however, there are two categories that I believe deserve most of our attention (thread).

These categories can be deduced by working backwards from the types of accounts available today, and the functionality each of them provide.

It's also important to note _why_ UX in Ethereum tends to be so poor:

Authentication is a critical building block for smart contracts. There needs to be a secure way to know "account X is okay with Y happening". Developers have turned to `msg.sender` for this functionality.

Since most user txs are from EOAs, they are only allowed to perform one authenticated action per tx. This graph shows how msg.sender is only set to their address once in the initial frame of the tx. The solution is to therefore allow accounts to both execute code & originate txs.

This leads us to the first category of design choices, Account Abstraction.

Allowing contract accounts to originate transactions is one of the oldest research problems in Ethereum. @VitalikButerin originally authored a post called "On Abstraction" in 2015. Unironically, this one of my favorite blog posts in crypto. blog.ethereum.org/2015/07/05/on-…

Over time, the idea of allowing contracts to originate transactions became known as "Account Abstraction" or "AA" for short. The idea continued to be refined, mainly by Vitalik. In February 2020 he authored a post that would become a turning point for AA: ethereum-magicians.org/t/implementing…

This post laid the foundation for the Quilt team's work in co-authoring the Account Abstraction EIP -- EIP-2938. A bit over a year later, this is still the most comprehensive proposal for a protocol modification to allow Account Abstraction. eips.ethereum.org/EIPS/eip-2938

The tldr; of EIP-2938 is that it introduces a new tx type which allows senders to specify an address that will determine the validity of the tx, and therefore be its originator. Clients can define a local limit of how much gas a tx may use to determine its validity in the txpool.

This is an exceptionally elegant way of abstracting the validation logic from the protocol. Unfortunately there are a lot of complexities lurking. Relying on state external to the originating account is tricky, because it requires executing all preceding txs to completion.

This breaks an invariant today that all txs can be validated in linear time, w.r.t the number of txs. We're continuing to see block producers become more sophisticated (re: flashbots), so this concern may be overstated.

Account Abstraction also doesn't solve one of the most poignant issue that plague smart contract wallets today: cost. It could be $20 for a simple proxy contract deployment to $500 for a full copy of a Gnosis Safe. AA will continue to require users to pay to deploy these wallets.

There is an interesting design space here where, along with implementing AA, all EOAs are simply replaced with a smart contract that emulates the current behavior. This could be an interesting way of upgrading the functionality of EOAs.
ethereum-magicians.org/t/we-should-be…

Moving on to the second main category I see for improving Ethereum UX at the protocol, we could implement a mechanism that allows EOAs to execute code in the context of their own account.

EIP-2803 and EIP-3074 are two candidates in this design space. After contemplating the Rich Transactions EIP we (the Quilt team & authors of EIP-3074) found it lacked the versatility that we desired in a solution to the UX problems.
eips.ethereum.org/EIPS/eip-2803

I've written in-depth about EIP-3074 and how it works, so I'll just link to a past thread

https://twitter.com/lightclients/status/1371911245561917441?s=20

@adietrichs and I gave a very comprehensive talk at @EthCC on EIP-3074. It's probably the best introductory resource for the EIP:

I believe EIP-3074 has three "superpowers":

1. It is incredibly flexibly + future proof.
2. Once an invoker is deployed, _all_ users can take advantage of contract wallet functionality.
3. Due to 2, it creates a schelling-point for contract wallet interfaces.

Superpower 3 is particularly interesting, because it sort of allows us to skip the coordination that would be required to get web3.js and ethers to begin supporting things like batch txs, expiring txs, etc in a way that Argent, Gnosis, etc. would all agree upon.

As we move to an L2-focused world, superpower 2 also shines. Migration into L2s becomes simpler+cheaper due to the tx batching now available to all users. Additionally, switching between L2s becomes easier, because the same contract wallet functionality is offered on each L2.

Although Account Abstraction and EIP-3074 may seem at odds with each other, I actually think they are rather complementary. EIP-3074 is a drop-in solution for authentication complexities in the protocol and AA allows relayer networks to be codified into smart contracts.

I've even written a short post about how EIP-3074 can be extended to support Account Abstraction in the future: ethereum-magicians.org/t/validation-f…

The gist is that wallets should focus on the aspect that make them unique, i.e. _validation_. Every wallet validates differently, whether it's verifying a different recovered address or using a different cryptographic primitive altogether.

The machinery that executes transactions is overwhelmingly not unique. Wallets tend to either originates a single call or multiple (batched) calls. This functionality can & should be separated from the validation logic.

/fin

I continue to be a proponent of the EIP-3074 first approach. AA is an elegant solution, but it has been researched for over 6 years and it's unclear when it may make it into an upgrade. EIP-3074 is a more straightforward solution to UX issues.