It’s an honor to share with you the topic of how wallets can better serve the general public in the future. Today, we'll primarily discuss the opportunities and challenges that wallets might face in the coming times. But first, let's delve into some design concepts of abstract account wallets.
In native transactions, users first create an account address (EOA) and then use the corresponding private key to sign a transaction, following the Ethereum standard. Once the signature is verified, the transaction is broadcast to the Ethereum network, where it is verified by validators, who charge miners fees and execute the transaction. This is the traditional transaction process.
However, our focus today is on AA wallets, highlighting how its transaction cycle differs from the conventional method. As shown in the diagram, there is an area circumscribed by a dashed line, a component not present in traditional transaction processes. This section can be seen as a piece of information, or "intent," signed by the user during the transaction, which deviates from the standard Ethereum transaction format. This "intent" represents the action the user aims to perform. The signing at this juncture resembles the EIP-712 signature method.
Now, who is responsible for gathering these "intents" and transmitting them to Ethereum nodes? The abstract account introduces a role called "bundler", which evaluates the transaction off-chain, determining if it can be successfully executed and whether the expected fees can be deducted post-execution. I refer to this process as "virtual validation." It simulates the validation before the transaction enters the actual transaction pool. The bundler then forwards the transaction to the relevant nodes, initiating the real transaction process.
Compared to native transactions, abstract accounts introduce three major innovations:
- Information Signature: In the past, what was signed conformed to the transaction's standard format. Now, only a piece of information is signed, like the destination of a transfer, rather than the full Ethereum transaction details.
- Distinction between Accounts and Signers: Traditionally, no account means no tokens. In the current scenario, the account holder and the signer are two distinct entities. This results in two primary shifts: through contracts, addresses can be pre-generated; since the signer isn't synonymous with the account, if the signature key is lost, a new signer can be appointed to recover the account.
Notably, regarding the pre-generation of addresses: In the past, if you wished to encourage someone to use a wallet but they lacked an address, even gifting a ten-dollar gift card was impossible. With pre-generated addresses, you can directly deposit funds when a user creates a new wallet. - Gas Fee Abstraction: Apart from account abstraction, the concept of Gas has also been abstracted. This means the gas fees you pay today doesn't necessarily have to be in ETH; it could be in ERC-20 tokens or any other fiat currency.
Key Management
One of the core aspects closely related to wallets is key management, undeniably a primary focus of ours. In the Web2 context, existing standards like Passkey, FIDO2, or WebAuthn provide us with convenient key management solutions.
However, abstract accounts revolutionize key management. Instead of just ECDSA signatures, we now embrace diverse signing methods. With private keys in phone security chips and contract validation, your phone transforms into a hardware wallet, making mnemonic phrases obsolete.
Abstract accounts enable us to replace the signer in the event of a private key loss while keeping the account unchanged. This amplifies the sustainability and upgradability of the wallet. Additionally, as these accounts are developed based on open-source contracts, their logic and verification methods are transparent to all users, allowing for more customization and a diverse range of frontend interfaces.
For example, there can be mobile apps or web versions, offering users more choices. The persistence of abstract accounts means that transaction histories or accumulated reputation on these accounts may potentially be used for DID in the future.
Addresses
The conventional method of generating blockchain addresses is based on the encoding of public keys. As long as you know the private key, you can deduce the corresponding public key and address. The advantage of this method is that it provides consistency across multiple chains. Users only need to manage a single private key to operate on various chains.
Due to the utilization of contracts, address management of abstract account wallets becomes more intricate. On EVM-compatible chains, addresses might still be traditional. However, on non-EVM-compatible chains like StarkWare and zkSync, the situation diverges. Despite these differences, through ENS management, users can still maintain operational consistency across multiple chains or Layer 2 solutions.
While native transaction address management is popular for its simplicity, abstract accounts introduce new challenges. Ensuring consistent user experiences across various chains and Layer 2 solutions, while taking into account the intricacy of contract accounts, is a problem that beckons future solutions.
Signing message
The signing message process in abstract accounts unveils unique potential and prospects. Unlike traditional native transactions, users are not restricted to a fixed transaction format and can freely express their intentions and desires. This flexibility brings about revolutionary changes to blockchain interactions.
In abstract accounts, signing messages aren’t merely instructions for fund transfers. Users can sign their intentions, specifying actions they wish to perform on the blockchain and applications. With this level of freedom, user interactions can occur across various scenarios, including email, social platforms, messaging apps, and more.
Users can simply write "Transfer 50 ETH to Alice" in an email, without having to go through a complex transaction interface, and the system will automatically recognize the intent and help users complete the transaction. This is similar to how we type keywords into a Google search bar without worrying about the underlying processing details. This model can be extended to various applications, allowing users to easily and quickly complete blockchain interactions almost anywhere.
Gas fees
Paying gas fees has always been challenging in blockchain transactions. Traditionally, users must ensure they have sufficient ETH in their wallets to cover transaction costs. This undeniably complicates matters, as they might need to first purchase ETH, possibly through fiat on exchanges or acquire it in other ways.
However, this issue has been greatly improved within the abstract account framework. Thanks to Paymaster, users are no longer limited to using ETH for transaction fees, reducing the entry barrier and complexity. Abstract accounts also allow for more customization of contracts, enabling them to be designed based on specific needs, including how to charge and pay for transaction fees.
This innovative approach ensures that users can effortlessly and seamlessly transact, elevating the overall user experience.
Account Recovery
Account recovery remains another pivotal consideration. Traditionally, mnemonic phrases have been our primary recovery tool. In abstract accounts, even if the signer changes, account continuity is preserved. This furnishes us with diverse account recovery methods, including multi-signatures, identity verification technologies, or even off-chain solutions like MPC. Such versatility enhances user confidence, knowing they have several recovery means should issues arise.
Given that abstract accounts are contract-based, this implies we can design more modular contracts, integrating various plugins and functionalities. From the changes in user portraits, we can see the diversity of user needs. A beginner may require a wallet that is user-friendly and straightforward, while as they gain experience and their needs evolve, they may desire a wallet with more advanced features, such as DeFi functionality or enhanced security measures.
To cater to diverse user needs, we can design contracts with assorted modules and features. Abstract accounts enable us to flexibly offer services tailored to users’ needs.
In conclusion, abstract accounts offer modular and customizable functions, further realizing differentiation and customization. Yet, high contract execution costs are a concern. We need to scale to cut costs, and we see future wallets leaning more on Layer 2 technology for abstract account implementation and execution.