Account Abstraction - a tale on the evolution of wallets

The history of money

In the land of Soliditium, gold was the cherished currency despite its heavy weight, causing inconvenience in transactions and storage. Sir Codelot, driven by his desire to ease the burden, devised a plan to revolutionize the way people conducted their financial affairs.

Sir Codelot devised a plan to implement a public ledger for tracking transactions, but with a catch: everyone would have their own key for secure access and participation. This revolutionary system would empower the people of Soliditium, granting them control over their own financial accounts while maintaining the utmost security.

He called it the Ledgereum.

Doesn't that sound familiar? This could be a brief description of the Ethereum network (and many others of course). Decentralized database, where you can control your assets on a specific account using a simple thing - a cryptographic key, 64 length hex digits number.

Now that we have the idea, we need to start implementing it.

However, here comes the first challenge – how to generate and manage the key?

The first challenge - randomness

Generating private keys proved to be a formidable task, given the requirement for them to be highly resistant to guessing. Sir Codelot understood the paramount importance of robust private key generation to ensure the security of individuals' accounts and transactions.

The most important attribute of the private key is its infeasibility to guess. Therefore it must be unique and long. That is why, one of the fundamental domains in cryptography are random functions, or to be more exact pseudo-random functions. They are used to generate private and public keys and other secret material.

The wizard Randulfus the Unique approached Sir Codelot, bearing a mystical artifact known as the "Hexstone". This enchanted gem possessed the extraordinary ability to generate a random number consisting of 64 hex digits whenever it was invoked.

It is important to remember that there are two types of pseudo-randomness in computer science, statistical and cryptographic.

• Statistical PRNGs (pseudo-random number generators) have useful statistical attributes, but the output is easy to guess and is unsuitable for secure parameters such as private keys.
• Cryptographic PRNGs return values which are more difficult to predict. For a value to be cryptographically secure, the attacker must not distinguish it from the truly random number.

In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts.

With the Hexstone in his possession, Sir Codelot realized the potential it held in addressing the challenge of secure key generation.

The first challenge has been solved, but then, the new one arises… the storage.

The first wallets - the brain and the paper

The people of Soliditium found it arduous to commit these lengthy strings of digits to memory, resulting in the unfortunate consequence of forgetting their keys. In a desperate attempt to avoid losing access to their accounts, many resorted to writing down their keys on pieces of paper, clinging to these precious reminders like lifelines in a sea of forgetfulness.

It is hard to remember 64 hex digits, not even mentioning possessing multiple accounts. Neither is it a good idea to write it down in plaintext as you can easily lose it if you have no backup. However, the more places you keep it in the plaintext the bigger risk the key may fall into the wrong hands.

That is why you must never keep your key in plaintext on paper, unless it is held in a physically secured places (yeah, backup!).

Review:

• adoption: LOW (hard to memorize, hard to recover),
• security: LOW (hard to keep secure).

The human brain wallet

Faced with the challenge of people struggling to memorize their lengthy keys, Sir Codelot's inventive mind sparked with a solution. He devised a brilliant concept to simplify the process while maintaining security. Sir Codelot proposed using a password, an easy-to-memorize phrase, as the base for generating the key. Through the use of sophisticated operations in the “Hexstone”, the password would serve as the foundation, undergoing complex calculations to generate the corresponding 64-digit key.

Quite straightforward idea to simplify the generation of the key is to use an easy-to-remember password and somehow transform it to the key.

The operation that does it is called a Key Derivation Function and is widely used in cryptography. In fact, there are many secure KDFs but the catch is that the security of the whole transformation lies in the password (also known as the master key).

Why? Because the KDF function is not a secret and knowing the password one can generate the private key easily.

Why is it still insecure? Due to the same challenges that relate to the passwords used in most of the Web2 apps… brute-forcing. Users tend to use easy-to-remember passwords and when your password is not complicated (long, with different types of chars), it might be easy to guess (or brute) within seconds. Knowing the password, one can easily drain your account.

To be safe, you could have a very complicated password. However if you are able to memorize it, why not memorize the key ;) ?

With his innovative solution in place, Sir Codelot closely observed the accounts of those who had adopted the practice of using passwords as the foundation for their keys. To his dismay, he noticed a disconcerting trend—these accounts were experiencing an unusual drain.

It became evident that malicious entities were targeting and exploiting the simplicity of the password-derived keys, employing advanced techniques to crack the code and gain unauthorized access.

Review:

• adoption: HIGH (easy to memorize, easy to recover),
• security: LOW (easy to brute-force).

The rise of seed and software wallets

As Sir Codelot pondered the security concerns surrounding the existing system, he delved into finding a more robust yet user-friendly solution, particularly in the realm of transaction authentication. He contemplated the role of messengers who carried signed transactions from individuals to the castle, where they were added to the ledger.

Think of the software wallets (e.g., MetaMask) as messengers who get the user’s transaction delivered to the mempool which is later picked up and added to the ledger.

The knight envisioned a novel approach that involved a foundation for the key—something challenging to brute-force yet easy to remember and write down. However, this key would not be used regularly; instead, it would serve as a backup for recovery purposes.

That foundation was called a seed phrase. The use of seed phrases was the first milestone in the evolution of wallets. Even though it has not solved all problems, it has became a standard. A 12 or 24 words from a predefined list of 2,048 English words, in a specific order, form the foundation of the key.

In this envisioned system, each individual would have the freedom to choose a trusted messenger. The messenger would be entrusted with an encrypted version of the key, safeguarded by a password personally selected by the user. When presented with transaction details, the messenger would swiftly decrypt the key, sign the transaction, and encrypt the key once more, ensuring secure transmission back to the castle. This revamped process would enhance both security and convenience, empowering individuals to safely engage in transactions while placing their trust in chosen messengers.

Does giving the key to the messenger sound scary? Well, when you use the software or mobile wallet it gets access to your transaction because it must sign it. It is your decision to use a particular software wallet and, consciously or not, you believe the authors of that wallet, probably the auto-updated one, do not introduce a backdoor to it.

As the new system utilizing trusted messengers was implemented, a remarkable shift occurred within the realm of Soliditium. Users swiftly embraced the practice of sending their transactions through messengers, finding comfort and ease in the familiarity of direct communication. Conversing with messengers allowed for a seamless exchange of transaction details, enabling individuals to articulate their intentions and requirements with clarity. The process felt natural, reminiscent of everyday conversations, and the people of Soliditium quickly adapted to this mode of transactional interaction.

With the use of software wallets, user experience has increased a lot. Users were used to applications handling payments and access to accounts (online banking, fin-tech mobile apps). It ended up being a nice balance between secure enough and easy-to-use applications.

A distressed villager urgently informed Sir Codelot about thieves posing as trusted messengers and potentially eavesdropping on messages. Recognizing the gravity of the situation, Sir Codelot pledged to investigate, enhance authentication, and reinforce the system's security to restore trust and protect the people of Soliditium.

Very quickly it turned out that malicious authors of software wallets are not the only security risk. The other, more likely threat, came from the Internet to which those wallets were connected.

When you keep your seed or private key on a computer that is connected to the Internet, it is exposed to a wide variety of attacks on the machine. It might be even easier when you are using a wallet in your browser.

Review:

• adoption: MEDIUM (easy to use, easy to recover password, hard to store seed phrase securely),
• security: MEDIUM (secure seed, still needs to be stored securely, trusted 3rd party).

The hardware wallet

As huge amounts of valuable assets were coming to the accounts, their owners needed a more secure way to manage them. However, it had to be optional and backward-compatible because users did not want to go through the whole path again.

At the request of Sir Codelot, the wizard Randulfus utilized his vast magical knowledge to craft a remarkable artifact known as the "Sentinel Sigil." This enchanted object served as a secure intermediary between users and messengers, alleviating the concerns of insecure messengers.

Users entrusted their private keys to the Sentinel Sigil, which required their password for access. When a transaction needed to be executed, individuals would input the transaction details into the Sentinel Sigil, which responded by generating a digital signature. The signature was then passed to the messenger, who now fulfilled a straightforward role as a mere courier.

Hardware wallets made it possible to separate private key storage from its usage. The idea was to keep the key on a device (in a secure element) and never reveal it.

The only option that a hardware wallet gives (besides the setup process) is the signing operation of a particular data (e.g., transaction details) that is executed on the device. Additionally, you have to provide another type of authentication, like a PIN or fingerprint to execute this signing operation. That is an additional protection in case of wallet loss or theft.

This is the current state of the art for wallets’ security and, together with the software wallets, they are quite widely adopted.

However, there are still caveats that stop it from the mass adoption, such as:

• setting up the accounts,
• need to have some Ether in the account to send the first transaction,
• integrating the account with third-party applications.

Review:

• adoption: MEDIUM (easy to memorize, easy to recover, high entry threshold),
• security: HIGH (secure password, stored securely).

The “ultimate” solution - account abstraction

As Sir Codelot observed the widespread adoption of Ledgereum among the people of Soliditium, he rejoiced at the increasing number of transactions facilitated by trusted messengers. However, his keen eye also detected a concerning trend. After a certain threshold of users was reached, the growth of Ledgereum seemed to plateau, unable to attract new participants.

The software and cold wallets did their job, and attracted a lot of people. However, still you cannot call it a mass adoption. They also offered different levels of security and basically became a big part of the market.

However, the challenges mentioned above still blocked wider adoption, because for some people it was too hard to start using wallets, for others the hardware wallets were too expensive and still others wanted to manage their resources in a different way altogether.

Sir Codelot delved deeper into the matter and discovered that many individuals harbored concerns regarding the security of their assets. The cost of acquiring and maintaining the Sentinel Sigil acted as a barrier for some, prompting them to seek alternative methods to safeguard their digital wealth.

Faced with these challenges, Sir Codelot realized the need to address both the limitations of growth and the desire for individual asset protection, and he set forth on a quest to devise innovative solutions that would restore confidence and encourage wider participation in the Ledgereum ecosystem.

Sir Codelot had a visionary idea. He envisioned a magical solution called "Codelot's MystiWallet”. This name embodies the mysticism and enchantment associated with the realm of Soliditium, while signifying the abstraction of wallets in the Ledgerum system.

Understanding the importance of simplicity and accessibility, Sir Codelot recognized the need to make Ledgereum usage as user-friendly as possible, without relying on new magical concepts. To gain widespread adoption, he devised a plan to offer free and intuitive access to Ledgereum, aligning it with the familiar methods people were accustomed to.

The current solution with the main goal of increasing adoption, but also addressing the security is Account Abstraction, also called by its number as ERC-4337.

In short, ERC-4337 introduces the standard for three main things: structures, infrastructure and flows.

1. Structures: It defines the structures of operations that users want to execute from their wallets. The wallet may not exist and will be created on the first operation. What is important is that the wallet includes the authorization logic which means that it can handle widespread of possible authorization mechanisms (with some limitations), including simple ECDSA signature verification, multi-sig verification but also a complex one, such as either simple ECDSA signature or multi-sig or signature by the key that is stored in your mobile phone (bypassing the requirement to have a private key specially crafted for the account).

2. Infrastructure: It defines actors that handle the operations (e.g., bundlers) and components that process them (e.g. entry point smart contracts).

3. Flow: Last part combines the previous two as following:

   • The user operation is sent to an alternative mempool, where it is picked up by the bundler.
   • The bundler creates a transaction that calls an EntryPoint contract to handle operations (and creates the Wallet contract if needed).
   • The EntryPoint contract verifies the user operation either by calling the Wallet contract or by calling the Aggregator contract (trusted by Wallet contract).
   • The EntryPoint contract calls the Wallet contract with data from the user operation (this is the main function call that is wrapped with the abstraction layer).
   • The EntryPoint contract decreases the balance of the Wallet contract to pay for the service, however there is an option that another contract, called Paymaster, will pay for the Wallet contract, e.g. when balance of Wallet contract is zero.

Realizing the importance of jump-starting Ledgereum adoption, Sir Codelot made a strategic decision. He dispatched the treasurer to reach out to the people directly, providing them with initial coins to facilitate their transactions with the messengers.

In short, the Paymaster solves the requirement of having Ether on the wallet contract, the Wallet contract deployed by EntryPoint contract solves the problem of complicated setup, and custom authorization mechanism solves the problem of key generation and storage.

Mindful of the potential confusion and complications that could arise from the existing messengers handling new operations and collecting payments, Sir Codelot made a prudent decision. He formed a separate group of operations collectors, distinct from the existing messengers, specifically tasked with managing these responsibilities. This new group would solely focus on gathering operations and ensuring the correct processing of payments.

Indeed, the lack of changes introduced to the consensus was one of the challenges. That is why the alternative mempool and new nodes (bundlers) have been introduced.

The Account Abstraction approach made the Wallet setup and usage very customizable, starting from simple usages for ordinary people and ending up with complex Wallets for whales or DAOs.

Review:

• adoption: HIGH (easy to manage, easy to recover, easy to set up),
• security: VARIABLE (dependent on the authorization protocol employed).

Conclusions

The ultimate word in the title of the previous section is quoted for a reason. This is the current idea for mass adoption and tends to be assumed as secure, but the reality is that its security is delegated to the authorization mechanism which can be simple and insecure or hard to use and secure. So, basically, the risk has been transferred.

With the success of MysticWallet and the growing adoption of Ledgereum, Codelot was pleased to see new users joining with different authorization methods. Craftsmen accepting payments through Ledgereum brought further joy.

However, he swiftly recognized the emergence of robbers who pretended to be craftsmen, deceiving and disappearing with payments.

It is also worth mentioning that some security risks are not considered by the account abstraction at all. That is the phishing for example.

Therefore, Account Abstraction cannot be treated as the security patch for Web3 and it must be remembered that its main goal was to increase adoption and not security.

• Did you like the article? Share it on social media!

Composable Security 🇵🇱⛓️ is a Polish company specializing in increasing the security of projects based on smart contracts written in Solidity. Examples of projects that have trusted us are market leaders such as FujiDAO, Enjin, or Tellor. We are creators of the Smart Contract Security Verification Standard. Speakers at various conferences such as EthCC, ETHWarsaw, or OWASP AppSec EU. Authors of numerous publications on DeFi security. Experienced auditors operating in the IT Security space since 2016.

If you need support in the field of security or auditing smart contracts do not hesitate to contact us.