first level title
we must continue to evolve
When someone first decides to dive into decentralized finance, NFTs, or any other type of on-chain activity, they realize they first need a wallet. Unfortunately, the experience of using an on-chain wallet is very different from what most people are used to. This is a significant pain point that deters millions of potential crypto users.
first level title
current system
There are two ways to implement a self-hosted wallet on-chain: using an external account (EOA), or a contract account (CA). Both are capable of sending and receiving digital assets and interacting with deployed smart contracts. However, they have some key differences, which are summarized in the table below.
Currently, contract accounts are usually only used for self-custody in the form of "multi-sig". Multi-signatures provide increased security, but are generally not a practical way for ordinary users to keep their assets on-chain, as they are much more complicated to set up than normal EOA wallets. Without account abstraction, contract accounts cannot easily be used as the main way to store digital assets.
For something to be called an "account", 3 important conditions must be met. Whether it is an external account or a contract account, these conditions must be met. Account must have:
1. Balance- This represents the amount of digital assets in the wallet
2. Nonce- This ensures that every transaction sent from the wallet is unique
3. Address- This is a unique identifier for each account on the web
secondary title
Problems in the EOA Model
It would be disingenuous to say that the current EOA design (which is the standard for wallets today) is fundamentally flawed, but it is certainly not in a state where billions of people around the world can use it. The main reason for this is that the signer has full control over the account. If you lose your signer, you will lose your account. If someone finds your signer, they own your account. While this might help hold users' assets under perfect conditions, we don't live in a perfect world. The security of the EOA wallet is entirely dependent on the user's management of a single private key. There is no safety net; there can be no mistakes. However, people are fallible, and wallets can't be this complicated if they're going to scale to the masses.
image description
Holders of monkey jpegs are under constant attack due to how difficult self-custody is at the moment.
first level title
Is account abstraction the solution?
secondary title
History of Account Abstraction
To properly implement the account abstraction and reduce the need for EOA accounts, it has long been believed that network-wide changes are required. Since 2016, Vitalik and other ethereum core developers have been drafting solutions for this change. Summarized as follows:
● EIP-86:Proposed by Vitalik Buterin in 2016, less than a year after Ethereum was first released. This EIP introduces the concept of a smart contract as a "forwarding contract" and only accepts transactions from "entry point" addresses, from which anyone can send transactions as long as they follow a specific format. This required major changes to the Ethereum protocol and was abandoned.
● EIP-1014: Proposed by Vitalik Buterin in 2018, this EIP takes the core ideas of EIP-86 and led to the creation of the CREATE 2 opcode. This allows us to predict the address where the contract will be deployed without actually deploying it. This is important because for smart contract wallets to work, we must ensure that the smart contract address is the same on all EVM chains, even if it is not deployed to all of them at the same time.
● EIP-2938: Proposed by Vitalik Buterin, Ansgar Dietrichs, and Matt Garnett in September 2020, the EIP attempts new "account abstraction" transactions that require the creation of new opcodes. This is proving to be too big of a protocol change, and it's not sure how it will play out. EIP-2938 is abandoned.
● EIP-3074: Created in October 2020 by Ansgar Dietrichs and Matt Garnett, this EIP introduces two new opcodes: AUTH and AUTHCALL. When used together, they allow smart contracts to send transactions on behalf of the EOA. As we have seen with other EIPs in the past, major network changes are unlikely to be approved. EIP-3074 is no exception and was not implemented due to security risks.
Notably, the EIP timeline shows that account abstraction has been on the minds of core Ethereum developers since the inception of Ethereum. With the merge done, more developer resources are finally available to consider the abstraction. The next EIP finally brings us closer to the next generation of wallets.
● EIP-4337 - Ethereum account abstraction without consensus layer changes:In September 2021, Vitailk, OpenGSN and Nethermind proposed EIP-4337 - Account Abstraction via Entry Point Contract Specifications. EIP attempts to accomplish account abstraction without requiring changes to the core protocol. This is a huge achievement, as protocol changes are what have prevented most progress so far. EIP-4337 is still in the draft stage and has not been finalized, but since EIP-4337 does not change the consensus layer, there are already implementations available, including OpenZeppelin and Stackup. The mechanism of this EIP function can be divided into three steps:
1. UserOperations,(essentially a normal transaction with an extra data field that enables account abstraction) sent via a custom mempool
2. Afterwards, UserOperations are packaged into a single transaction by Bundler. Bundler will choose which UserOperation objects to include based on fee priority logic, similar to how miners operate in existing transaction mempools. The bundler (using a service like Flashbots) calls the EntryPoint contract for verification
3. If there are no errors, the transaction will be included in the next block of the network
The EntryPoint contract is a key part of the infrastructure invoked through Bundler. Calling this smart contract first verifies that the UserOperations follow the account's pre-specified rules, and then executes them. It's important to remember that EIP-4337 has no protocol-level changes. This means that Bundler is an EOA address that commits all these transactions to the chain. The EntryPoint contract can be further extended by adding a Paymaster. Paymaster offers some benefits:
1. It allows app developers to pay on behalf of their users
2. It allows users to pay fees in ERC 20 tokens, and the contract acts as an intermediary to collect ERC 20 and pay gas fees in ETH
secondary title
Application Scenarios of Account Abstraction
image description
Smart contract wallets are a major upgrade in terms of features compared to EOA wallets - Source: Argent Wallet on Twitter.
social recovery
One of the most important benefits in terms of protecting users' digital assets is that social recovery is designed to protect users who lose their signing keys. Imagine if a user's laptop broke and they misplaced a physical copy of their private key or seed phrase. In this case, with EOA wallet, all your assets will be lost forever. Social Recovery takes a different approach, rather than using a mnemonic phrase to recover wallets. This is Vitalik's favorite way of securing a wallet, and he defines how it works:
1. There is a "signing key" that can be used to approve transactions
2. There is a group of "Guardians", most of whom cooperate to change the account's signing key
If users lose or forget their signing keys, social recovery can be activated. Normally, if I lose my signing key and seed phrase, I cannot access my account. With social recovery, users can simply contact their guards and ask them to sign a specific transaction to change the signing key registered in the wallet contract to a new one. Although there are some mechanical differences, this is conceptually similar to what happens when you forget your Google Account password and need to regain access to your account.
There are many possible options for who to choose as a bodyguard. The three most common options are:
1. Other devices owned by the wallet holder
2. Friends and family
3. Agency, if they get confirmation with your phone number or email, or in high value cases, possibly via video call to verify your personal identity, they will sign the recovery message
image description
Screenshot of Unipass wallet’s UI for adding a guardian
UniPass Walletis an upcoming smart contract wallet, one of its main functions is social recovery. UniPass Wallet includes an interface to seamlessly add and remove Guards.
Role-Based Access Control
For many traditional "web2" applications, platform developers require users to enable two-factor authentication (2 FA). This automatically prevents a lot of hacking from happening.
It's worth noting that many other articles will claim that multi-factor or two-factor authentication via text message or email address is a new feature unlocked by owning an account abstraction wallet. Implementing this form of 2FA typically leverages multi-party computation (MPC) and off-chain servers. There is not yet a purely on-chain implementation. But since it is powered by MPC technology, it can also be implemented using only the EOA wallet. It would be disingenuous to say it is exclusive to account abstraction wallets.
However, smart contract wallets can enable similar types of on-chain functionality by requiring your hot wallet to be used as a form of secondary confirmation. This automatically prevents a lot of hacking from happening because even if you get phished, you may still need confirmation to transfer your assets. Account abstraction wallets allow you to define specific security parameters according to your preferences. Examples of this might include:
● Set a daily transaction limit to specify the amount of currency you can send per day, unless you confirm it through a hardware wallet. This prevents your wallet from depleting all at once.
● Connects to a database of well-known "scam" addresses, if the address you are interacting with is stored in the database, it will immediately prompt you to additionally confirm the transaction with a hardware wallet.
● Check the Opensea collection and let you know that you are buying an unverified NFT collection, and prompt you to confirm through a hardware wallet, preventing confusing purchases of counterfeit/malicious NFTs.
Most importantly, all of these features provide a multi-layered safety net when performing on-chain interactions. Most users have no idea what they are signing or approving. Right now, we're running on a system where one misclick instantly drains wallet balances, and that needs to change.
session key
Many believe that blockchain games will be the next big story in web3. For this, there needs to be a better user experience than currently exists. It doesn't make sense for users to have to approve multiple functions every time they want to interact with something in the game they're playing. This isn't how traditional games work, and can turn people off with the unfamiliar and cumbersome interface. Session keys allow users to pre-approve transactions for an application based on a set of parameters: a given duration, maximum gas, maximum transaction volume for a specific token, or specific functionality for a specific contract. Users will be able to pre-approve their session with some basic terms, hit play and play without being constantly bombarded with their wallet asking, "Confirm this transaction".
batch transaction
Now, if I want to use a dapp, I need to make a new transaction for every on-chain interaction. This is annoying and costly since every approved interaction costs money. By abstracting accounts from accounts, wallets can bundle multiple transactions together and execute them as one transaction.
This radically simplifies the user experience. Complex transactions and yield mining opportunities can be simplified to just one click.
Other application scenarios
secondary title
Potential problems with account abstraction
The account abstraction wallet is currently not implemented at the protocol level, and currently only exists as a smart contract, and gas is relayed in a creative way. Because these wallets are smart contracts, some problems arise. First, there is a cost to deploying a smart contract wallet because it uses blockchain storage. Currently this can be circumvented by using a cheaper chain or by making relayers bear this cost. However, this doesn't really avoid the higher gas cost of submitting transactions. The gas cost of a single transaction sent through the smart contract wallet is more expensive than that sent through the EOA wallet. It could be improved with proper transaction batching, but we're not there yet. The second more important issue is that every wallet needs to be audited before it can be used as a replacement for EOA. If a widely used smart contract wallet had a vulnerability, it could be one of the biggest hacks ever. This is not just hypothetical, as smart contract wallets have been hacked before. In 2017, the Parity smart contract wallet150,000 ETH stolen(worth $180 million today). Three months later, the same smart contract was hacked again500,000 ETH stolen(worth $600 million today). Fortunately, we've improved our security standards since 2017, and most of what account abstraction wallets are trying to do these days isn't outrageously complex. Security features like social recovery and role-based access control are also built in by default, which provide a level of protection against problems with the smart contracts themselves. However, even with these features, the current implementation of ERC-4337 still has security issues. The biggest problem is that the EntryPoint contract is extremely privileged. If there is a security issue with this smart contract, hackers can use it to exploit any ERC-4337 contract wallet. In addition to security concerns, the infrastructure to support ERC-4337 is imperfect. The current implementation of ERC-4337 relies heavily on Flashbots. Flashbots are critical to account abstraction, as it packages a set of UserOperation objects into a single "bundled transaction", which is then included in an Ethereum block. Flashbots are specific to Ethereum itself, which calls into question how ERC-4337 wallets are compatible with other EVM chains. While contract wallets can be deployed to another chain, without a Flashbots-like mechanism for bundling transactions, the wallet would be unusable. Finally, smart contract wallets can only interact with decentralized applications that implement EIP-1271, calling EIP-1271 to verify the signature of the contract wallet. In theory, if Opensea or any other decentralized application has not implemented EIP-1271, the smart contract wallet will not be able to interact with the application and become useless.
secondary title
Layer 2
secondary title
UniPass, an account abstraction wallet
While Argent Wallet (a great account abstraction wallet) is focused on layer 2 like Starknet, it is important that we see implementations on layer 1 like Ethereum. UniPass is an account abstraction wallet built with a set of features that set it apart from the competition, including EOA wallets and other account abstraction wallets. When a UniPass user initiates a transaction, a third party is required to act as an intermediary to complete the transaction. In this process, the relayer can allow users to use any supported tokens to pay gas fees, and even pay gas fees for users, so as to achieve a gas-free user experience. UniPass will provide a default UniPass relay node that you can use out of the box. Initially, UniPass Relayer will accept gas payments in its native token and mainstream stablecoins. Additionally, applications can build their own client repeaters to meet the needs of their user base.
image description
Creating a wallet is as simple as logging in with your Google Account
UniPass also has a unique on-chain email-based verification technology for social recovery. Email protocols (POP 3, SMTP, and IMAP) have been around for over 50 years and are a fundamental part of the modern Internet. To protect email from malicious modification, DomainKeys Identified Mail (DKIM) was introduced in 2004. DKIM is a standardized email authentication technology. Senders are able to add a digital signature to outgoing email. When an email server receives a signed email, it can verify that the email is from the actual sender and that the content has not been modified.
After continuous research, UniPass Wallet can now use on-chain smart contracts to verify DKIM's digital signature. This allows users to manage their non-custodial contract accounts and use email only for social recovery. Typical social recovery solutions for smart contract wallets, such as Argent's, require guardians to be Argent users or already have an Ethereum wallet. This means that if your trusted family and friends are not web3 users, they cannot act as guardians of your account. Through the structure of UniPass, users can set multiple mailboxes as the guardians of the account, and only need to submit the emails to the smart contract on the chain to help users set up account recovery. This greatly lowers the barrier to entry for guardians, allowing all your family and friends who have an email to become guardians of your account.
epilogue
epilogue
secondary title
author
secondary title
statement
Original link
