“What's in a name? that which we call a rose;
By any other name would smell as sweet.”

What is an account? I think there is more than just its name - what is its essence, in our decentralized world?

I think this is an important question (or definition) we need to make, and once we do, we should explain what we mean by abstracting it.

The definition I like for an "account" is that it is the smallest entity that can autonomously operate on the network.

That is, it doesn't need any intermediary (well, except the decentralized network itself) to run transactions.

This is an important distinction: we don't call the network (rpc endpoints, nodes) “intermediaries” - because there are so many of them. Because I can always decide to use another, if the one I'm currently using is less performant, inaccessible, or selfishly decides not to serve me anymore. The network is also built with incentives to make sure there will always be one to serve me.

So we don't consider those nodes as "separate services", but all as a single, amorphous "decentralized cloud" which always exists and will always serve me.

An EOA is obviously an autonomous account: This is what we use to cast votes, run games, and do our DeFi trades.

But we're now in account-abstraction land, and EOAs are not enough for accounts, and we want smart-contracts to act as accounts.

But what does it take for a contract to be an account?

To answer this question, I get back to the basics: Can this "account" run autonomously? Or am I tied to some service provider or some backend servers to submit transactions?

This is the question we always thought of when we added features to the ERC-4337 standard. We did add an ability to "delegate" gas payments to an external entity (a paymaster) which can be implemented as an external service that might even allow me to use my credit card for transactions. It is nice to have such helper services, but the crucial point is that I don't have to use such a service: I can always get “back to basics”, send some eth into my account, and issue transactions directly to the network.

Some would claim that even ERC-4337 "accounts" are not real accounts - after all, they require "bundlers", which are essentially EOAs, to submit those UserOperations on-chain.

In essence, that's true - for now. But here is the difference: while currently, bundlers are such "centralized services", which you must select and use, they are designed as “nodes” or “block-builders”. Their architecture, the UserOperation structure (which closely resembles a transaction), validation rules, and most importantly - the yet-to-be-launched mempool, will all make bundlers run as network nodes. The result? More traffic of ERC-4337 UserOperations, which means more builders also include 4337 UserOperations and become more profitable and end up building most of the blocks, and eventually most of the network builders are also 4337 bundlers. They are no longer individual services, but transformed into those amorphous entities in this "cloud".

Since we built the protocol that way, this change (from individual service nodes to a decentralized cloud) will happen without any change (or even knowledge) to the accounts and applications that use it.

So the next time you look for a framework for building an “account abstraction based” application, think of the underlying contracts, and how much are they really autonomous accounts.

“What's in a name? that which we call a rose;
By any other name would smell as sweet.”

What is an account? I think there is more than just its name - what is its essence, in our decentralized world?

I think this is an important question (or definition) we need to make, and once we do, we should explain what we mean by abstracting it.

The definition I like for an "account" is that it is the smallest entity that can autonomously operate on the network.

That is, it doesn't need any intermediary (well, except the decentralized network itself) to run transactions.

This is an important distinction: we don't call the network (rpc endpoints, nodes) “intermediaries” - because there are so many of them. Because I can always decide to use another, if the one I'm currently using is less performant, inaccessible, or selfishly decides not to serve me anymore. The network is also built with incentives to make sure there will always be one to serve me.

So we don't consider those nodes as "separate services", but all as a single, amorphous "decentralized cloud" which always exists and will always serve me.

An EOA is obviously an autonomous account: This is what we use to cast votes, run games, and do our DeFi trades.

But we're now in account-abstraction land, and EOAs are not enough for accounts, and we want smart-contracts to act as accounts.

But what does it take for a contract to be an account?

To answer this question, I get back to the basics: Can this "account" run autonomously? Or am I tied to some service provider or some backend servers to submit transactions?

This is the question we always thought of when we added features to the ERC-4337 standard. We did add an ability to "delegate" gas payments to an external entity (a paymaster) which can be implemented as an external service that might even allow me to use my credit card for transactions. It is nice to have such helper services, but the crucial point is that I don't have to use such a service: I can always get “back to basics”, send some eth into my account, and issue transactions directly to the network.

Some would claim that even ERC-4337 "accounts" are not real accounts - after all, they require "bundlers", which are essentially EOAs, to submit those UserOperations on-chain.

In essence, that's true - for now. But here is the difference: while currently, bundlers are such "centralized services", which you must select and use, they are designed as “nodes” or “block-builders”. Their architecture, the UserOperation structure (which closely resembles a transaction), validation rules, and most importantly - the yet-to-be-launched mempool, will all make bundlers run as network nodes. The result? More traffic of ERC-4337 UserOperations, which means more builders also include 4337 UserOperations and become more profitable and end up building most of the blocks, and eventually most of the network builders are also 4337 bundlers. They are no longer individual services, but transformed into those amorphous entities in this "cloud".

Since we built the protocol that way, this change (from individual service nodes to a decentralized cloud) will happen without any change (or even knowledge) to the accounts and applications that use it.

So the next time you look for a framework for building an “account abstraction based” application, think of the underlying contracts, and how much are they really autonomous accounts.