Improving UX for ETH wallets
If you have been watching the Ethereum news lately, by now you should have already heard about account abstraction and its myriad of possible use cases.
In this post, I will walk you through the main components your protocol needs to be able to support Account abstraction, a Smart Contract Wallet implementation example using the zkSync blockchain, the projects currently supporting it, and finally some more possible use cases according to interviews with founders and members of teams like Argent Wallet, Alchemy and ZkSync.
Motivation
Account abstraction represents significant progress in ethereum mass adoption. This change will facilitate the onboarding and management of new users.
Major cases include companies that could pay for your transaction fees, and you would be able to pay transactions in erc20s. And now with Argent, you are able to sign transactions with the iPhone biometrics or face recognition. You would be also able to customize your authentication logic using other addresses as guardians and make your transactions multi-signature in nature.
ERC overview
In the past, all Ethereum Request for Comments have been standards that involve specific routines in a single contract. The ERC4337 is the first request that involves more than a single contract, it is a set of on-chain and off-chain components that allows users to leverage the power of smart contracts as their primary account.
Currently, a transaction can only “start from” an externally owned account (EOA), which has one specific authorization policy: an ECDSA private key signature. With account abstraction, a transaction could start from accounts that have other kinds of authorization policies, including multi-sigs, other cryptographic algorithms, and more complex constructions such as ZK-SNARK verification.
ERC4337 will allow the innovation of Intent-based architectures.
ERC 4337 Components
UserOperation - a structure that describes a transaction to be sent on behalf of a user, is not allowed to access block data and it is not a regular transaction type.
Sender - the account contract sending a user operation.
EntryPoint - a singleton contract to execute bundles of UserOperations. Bundlers/Clients whitelist the supported entry point.
Bundler - a node (block builder) that bundles multiple UserOperations and creates an EntryPoint. handleOps() transaction. Note that not all block-builders on the network are required to be bundlers
Aggregator - a helper contract trusted by accounts to validate an aggregated signature. Bundlers/Clients whitelist the supported aggregators.
Paymaster - optional contract that will subsidize the transaction costs for the
Supporting smart contract wallets
Suppose you would like your protocol to support Account Abstraction and smart wallets. In that case, your project needs to stop using ECDSA recovery to validate signed transactions and start using EIP-1271 which is a standard way to verify a signature when the account is a smart contract, more specifically, start validating user operations with a library that supports both cases like the OpenZepellin. "Signature checker" which supports EOA and EIP-1271 signatures.
This will improve your application user experience, allowing them to use regular EOA wallets or smart wallets, and your system to identify and register either option.
ZkSmart Wallet
The bootloader (yul contract) is a key component of the system that manages the execution of layer 2 transactions. It is specialized software that is not deployed like a regular contract but runs within a modified node as part of the execution environment. The validator modifies transactions and stores them in an array, which is then written to the bootloader memory and executed.
Follow the ZkSync installation guide then
Deploy an Account Abstraction Factory contract
Using create2Address, precompute an address derived from two EOA addresses, this will be the address for the Multisignature Contract Wallet.
zkSync Goerli contracts
EOA owner1: 0x1d3Af21a1889A1262980Fb8021bF91B792584A88EOA owner2: 0x6C181A9892DDA85182B3b44ce2C2CFFe53278D5dMultisignature address: 0x77A77362c777a6314582b76B653ba3BAE3Db976BDeploy multi-sig Smart Wallet contract at Multisignature address
Deploy a new AA via the Factory contract using the Multi-sig contract
Using a paymaster extension
Deploy Paymaster contract capable of paying for user operations
Set the currency type to pay transactions with
Fund the paymaster to pay for user operations
Send user operations from the smart wallet
Security Considerations
The entry point contract must be heavily audited and formally verified because it will serve as a central trust point for allERC-4337. In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual accounts have to do becomes much smaller (they need only verify the
validateUserOp function and its “check signature, increment nonce, and pay fees” logic) then
check that other functions are msg.sender == ENTRY_POINT gated (perhaps also allowing msg.sender == self),
but it is nevertheless the case that this is done precisely by concentrating security risk in the entry point contract that needs to be verified to be very robust.
Use Case: Argent Wallet, zKSync and Starknet
Key new wallet features
Multicall bundle multiple tx's into one
Meta transactions & relayers, users sign intents to transit, relayers broadcast and pay gas.
Session keys Sessions can be defined in a variety of ways. The parameters could include: “a given duration, a max amount of gas, a max transaction volume of a certain token, or a particular function on a particular contract
Social Recovery - Trusted contacts or 3rd parties Guardians
Multi-factor auth, use off-chain services
Plugins to wallet
Pay fees in any token
Pay fees on behalf of users
Different signing schemes allow more than ECDSA
- Phones as recovery wallets
The new, off-chain recovery method
The new process combines encryption and Cloud storage. As with recovery with guardians, we built it to protect you even if an attacker somehow seizes control of your device. Argent is the only wallet that offers this level of security. Here's how to use it.
This split gives you added protection. If anyone gets access to your iCloud or Google Drive, they can’t decrypt your keys without the KEK that Argent has. And if a malicious actor gets access to our infrastructure, they won’t be able to access your wallet as they won’t have your encrypted private keys.
1st level of security
A significant benefit of this level of security is that it would protect you even if your private key was somehow compromised. Nevertheless, to protect your private key, we also use all the available security features on iOS and Android, such as biometrics, keychain, and Secure Enclave, as well as a six-digit user pin code. The pin code helps to encrypt the private key (for those of you interested in cryptography: we use PBKDF2 and AES256 in Galois/Counter Mode).
2nd Level
Transaction protection for DeFi & Dapps To combine control and convenience, you can use Trust Lists and Trusted Sessions.
We've started with the "Argent Trust List". Key details:
The list includes the specific Dapps and functions integrated natively within Argent (e.g. Paraswap, Compound, Aave, Lido).
It's managed by us to stay in sync with those integrations. For security, it has a 1-week timelock for adding a Dapp, while removing a Dapp is instant. You can read more on this here.
You're always in control. The list will be active by default but you can disable it in a tap. In doing so you're making your Argent wallet a full multi-signature wallet.
Sessions can last: 1 hour, 3 hours
How do Sessions work?
Through the app, you'll create a new, temporary private key. Once authorized by your guardians, that key will be able to take any action without guardians for the duration of your session.
At the end of the session, the key becomes useless and is discarded. You can, of course, cancel a session at any time if you change your mind.
Wallet locking
You can ask a guardian to lock your wallet. The wallet can’t then make transactions. This is useful in case your phone is lost or stolen and you want to protect it beyond the phone-layer security.
When a guardian locks a wallet, a 5-day security period starts. This gives you time to get a new phone and recover your wallet. (Locking doesn’t prevent recovery, for precisely this reason).