Abstracting Away Account Abstraction on Polkadot

I recently had the fantastic opportunity to talk about Account Abstraction in a Twitter space hosted by IoTeX.

The perspective on just how exciting ERC-4337 seemed was refreshing. We were finally shifting towards solving problems that realistically plague adoption from both a developer and user experience.

A prime example of why Account Abstraction was necessary, besides the increase in DX/UX, was the ability to now change certain aspects of accounts without altering the consensus or protocol layer.

However, being the only non-EVM-related speaker there and familiar with Polkadot’s forkless upgrades, it was quite a curious event.

As a Technical Educator at the Web3 Foundation and someone who toys with Substrate a fair amount, not only did Polkadot not have most of these problems - its core architecture avoided them completely.

Account Abstraction is useful for Ethereum, as it provides a way for accounts to have less security risk and more utility, but it also led me to the question:

Does Polkadot have account abstraction?

Account Abstraction & ERC-4337

Before diving into the intricacies of Polkadot and Substrate, what exactly is Account Abstraction?

Cryptographic keys represent accounts on blockchains. In Ethereum, you may hear them referred to as “EOAs” (Externally Owned Accounts). On Polkadot, they are mostly referred to as just “Accounts.”

Either way, they represent the same thing - a cryptographic keypair used for approving network transactions.

It’s these keys that are both the problem and beauty of web3.

On the one hand, it allows users to take ownership of their actions and has full control via cryptographic signatures that verify state changes. On the other, if this key is lost - so is the entire digital basis for doing anything meaningful.

Identity, wallet, and digital presence represented by a single, off-chain key is both an attack vector and key to digital freedom.

Over time, they have become notoriously difficult to work with and keep safe - especially for the average user. It is one of the many deterrents or points of confusion for adoption.

Developers are included in that bracket. Compared to a traditional “web2“ app, how a developer must think while developing a web3 application changes in terms of security.

They must assume the worst and ensure no flaw is present in allowing the user to authenticate themselves, conduct actions, and ensure their keys cannot be compromised.

If your platform has irreversible smart contracts, one must be extra cautious before allowing private keys to sign off on potentially sensitive actions.

Account Abstraction saves the day by providing a layer of on-chain logic in the form of a smart contract (in the case of Ethereum) to control an account.

It abstracts away some of the importance of managing a single master key and reduces the complexity of use and the likelihood of it being compromised.

For example, it can change the signature algorithm to be quantum-resistant, provide custom logic for what can and cannot be performed with that account, and more.

It provides another layer of somewhat non-intrusive dynamism for networks where upgrading via a fork is an arduous process to, let's say, change a core part of the consensus.

But when the term “Abstraction” is used, what is meant by it exactly?

The True Meaning of “Abstraction”

Abstraction, in this context, refers to the idea of separating the user experience from the private key. Instead of the key having 100% power over every single action, a piece of code can dictate exactly how an account should act instead.

In other words, it can govern a key on terms the user provides.

In Ethereum, this is done by creating a smart contract that effectively allows the EOA to act as a smart contract. This smart contract acts as an on-chain arbitrator that can be programmed to allow the account to be recovered, change the way transactions are signed, and more.

These changes can be done without changing the core protocol, which would involve a complex fork.

In Polkadot, the implication of “abstraction” works is slightly different. By its very nature and core design, Polkadot has an incredibly generic (sometimes referred to as abstract) codebase built on Substrate and Rust.

This generic codebase allows accounts to be defined as whatever the protocol deems valid.

Likewise, primitives such as cryptographic signatures can also be changed if needed, frequently in just a line or two of code.

Remember, Polkadot is not a general-purpose chain - it serves as the relay chain for other chains, called parachains, to connect to. This architecture allows parachains to achieve interoperability and shared security while increasing scalability with each added chain.

Both parachains and Polkadot are built using Substrate. Certain primitives and types are left intentionally vague, allowing developers to choose exactly how accounts, amongst other things, should behave and look like.

Does Account Abstraction Exist in Polkadot?

Most of ERC-4337’s concepts are baked into Polkadot in the form of various pallets. Pallets comprise a runtime, a Substrate-based chain's core business logic portion.

For example, runtimes in Substrate can be upgraded to include new signature types, schemes, or block authoring methods. A runtime represents the state transition function of a particular chain, or shard, in the network.

However, a large part of what makes Account Abstraction useful is its ability to add new and improved account functionality.

While there isn’t a single pallet that achieves end-to-end account abstraction, several pallets provide the same functionality. They can be utilized to create common use cases for abstracting away an account from its private key.

Proxy accounts allow an account to be represented role-based, such as a proxy account for governance or staking. These accounts are the primary mode of abstraction away from the user's primary key and reserve them for specific roles within the network.

The recovery pallet also has an "M-of-N" social kind of recovery in case an account is lost, where an account’s access can be regained with the help of selected trusted individuals. Functionality such as batching can be done with the utility pallet.

It is also possible to design a pallet that does all of this in a single context and allows users to define their own rules for how they wish to provide an abstraction for their accounts.

Using existing pallets, however, it is very plausible to construct account abstraction mechanisms that secure and add logic on top of accounts.

Even recently, InvArch, an up-and-coming (soon to be) parachain on Polkadot, provided something that transcends typical account abstraction via a multichain multi-sig mechanism called Saturn accomplished using a Threshold Signature Scheme (TSS) and XCM, Polkadot’s cross-consensus message format.

Again, applications like this are possible because many things in Polkadot (including XCM) are made to be generic and abstract.

Conclusion

The future of scaling web3 technologies is through generic design. As time progresses, the space is beginning to take on more of the role of generating truly open infrastructure for development. Meanwhile, these abstractions make their way into user-facing applications and experiences.

The solution to adoption won’t be marketing blockchain or even web3; rather, it’s the accessibility to services that improve user experience and security and fulfill a need. Concepts such as account abstraction in Ethereum and Polkadot are just a small part of enabling this to happen.