The Future Wallet: Where Lit & Account Abstraction Meet

The recent downfall of FTX has sparked conversations about the safety and security of wallets and keys. In this article, we will dive into the world of Account Abstraction and Lit, a decentralized network for multiparty computation. To begin, some definitions:

Account abstraction (AA), can be thought of as programmable transaction validation (shout out to camiinthisthang). AA is a technique that allows the use of smart contract wallets containing arbitrary verification logic to confirm the conditions of a transaction programmatically. It moves crypto from the current approach of one-account-fits-all, where someone can lose everything with a small mistake, to a future where an account can be tailored to people’s needs. AA is a highly effective solution to address significant user experience issues in web3.

While exploring account abstraction, we want to introduce multiparty computation (MPC) wallets and they can work in conjunction with AA. An MPC-powered wallet can support anything and everything a normal self-custody wallet can with the added benefits of cross chain compatibility and the ability to process off-chain information.

Lit leverages multi-party computation (MPC) to provide a blockchain-independent middleware layer that enables secure reading and writing of data between blockchains and off-chain platforms. With the added benefits of encryption, access control, and programmatic signing, Lit enhances the capabilities of what’s possible with account abstraction, such as allowing compute of off-chain data with on-chain conditional signing.

Below you’ll find:

• An overview of account abstraction, smart contract accounts, and MPC
• Use cases of account abstraction with Lit Actions & Programmable Key Pairs (PKPs)

“MPC and smart wallets are not competitive, but rather complementary in the long term. MPC gives shared security at the key generation and management level, while smart contracts bring extensibility and an ecosystem approach to feature and application development.” - Nichanan Kesonpat, Seedless Self Custody: On MPC and Smart Contract Wallets

Account Abstraction and Multi-Party Computation (MPC)

Account abstraction in this post references EIP-4337. This EIP is the first proposal for account abstraction on Ethereum that can be implemented without changing the core protocol. It accomplishes this by shifting the validation of transactions from the protocol to the smart contract level with a specific entry point. With it are abstractions for a user's account, standardized smart contract account interfaces, and gas abstraction. This is possible by separating the transaction's signature from the account address, allowing for possibilities like switching between different accounts in a single transaction. EIP-4337 sets a standard interface for everyone to work with when creating smart contract accounts.

MPC (Multi-Party Computation) enables multiple parties – each holding private data – to evaluate a computation without ever revealing any of the private data held by each party (or any otherwise related secret information). An MPC wallet is a smart contract wallet whose public private key is divided, encrypted, and shared among multiple parties, in Lit’s case the key is stored across the Lit nodes and only an authorized party can decrypt and recombine the key shares to generate a signing key.

MPC allows for authorization processes to occur outside of the blockchain, the underlying key generation and signing rely on cryptography off-chain. Despite this abstraction, users will need a solid understanding of blockchain technology to use MPC wallets securely.

Another strength of MPC lies in its ability to handle signatures, enabling it to be used in conjunction with decentralized applications (dApps). This composable nature of MPC makes it a versatile cross-chain technology. For example, MPC can work with various blockchain networks that utilize elliptic curve signatures, including but not limited to Bitcoin. Expanding compatibility to additional blockchains lies in the capability to produce signatures the networks can decipher.

Benefits of AA

The use of blockchain technology is not without its challenges, even for those who are web3 natives. One wrong signing could result in a wallet getting drained, as we’ve seen recently with the founder of Moonbirds signing a transaction that compromised his account resulting in over $1 million in NFTs lost. Ensuring a seamless, secure, and user-friendly on-chain experience is one of the biggest challenges facing the blockchain industry as it strives for mass adoption. Can we realistically expect billions of people to engage in financial activities such as borrowing, lending, investing, and paying through a system that lacks basic security measures and safety nets? Without safeguards, the widespread adoption of blockchain technology remains uncertain.

We need a future ”where users can make mistakes without delegating their ownership to a central service. One where users are fully in control yet can sleep at night without being afraid of losing it all. One where users don't need to choose between self-custody and convenience. Such solutions already exist today and leverage smart-contracts to program the safety nets that users expect.” - Julien Niset, Self Custody Mass Adoption

The potential for these advancements is rooted in the core mechanism of account abstraction, which enables the setting of transaction validity conditions to be determined programmatically. This means that transactions can be made in a way that is both automated and controlled by pre-defined rules, creating a flexible and adaptable system for transactions.

Some examples of how AA enhances user experience:

• Programmed security - The requirement of additional confirmations in the event of fraud detection such as two-factor authentication, additional signing with a web3 wallet, or confirmation through another smart contract.
• Social Recovery - In What is a Social Recovery Wallet by Vitalik Buterin, he writes a good wallet design needs to satisfy three key criteria: no single point of failure, low mental overhead, and maximum ease of transacting. Social recovery can look like a multi-signature transaction to approve changing a signing key if an account has been compromised or lost.

Benefits of Lit (an MPC Network)

Lit Actions and PKPs

Lit Actions are Lit’s native implementation of JavaScript smart contracts that are blockchain agnostic. They can communicate data across blockchains, interoperate between previously disconnected ecosystems, and use off-chain data sources in their computation by making arbitrary HTTP requests.

Lit Actions are used in conjunction with Programmable Key Pairs (PKPs) to give smart contracts signing capabilities. Each PKP is generated collectively by the Lit network in a process called Distributed Key Generation (DKG) whereby each node only holds a share of the underlying private key (a key-share) and the complete private key never exists in its entirety.

To control this distributed key pair, you must mint it in the form of an ERC-721 NFT. The NFT stands as the “symbol” or method for controlling the distributed key custodied by the Lit network. This means that only the wallet address or smart contract holding the PKP NFT can authorize how it is used for signing.

PKP signatures are the validation result of Lit Actions code when using a signature to prove that a particular interaction took place. Lit Actions can validate the information from external sources, such as from a Weather API, or data that is stateless such as checking if a number is prime.

Ideal cases for PKPs and Lit Actions

• Generating proofs
  ideal for usage with AA wallets, essentially this is programmable transaction validation through Lit’s network with a signer
• Looking up permitted actions, addresses, and auth methods associated with a PKP
• Checking access control conditions with conditional signing

Some examples of how Lit Actions and PKPs can be utilized with account abstraction:

1. Conditional gas payments - PKP wallet pays for gas fees when certain conditions are met.
2. User Onboarding - creating a smart contract account for someone new to web3. The signer can start as an MPC key authorized through a web2 account.
3. AA wallet authorization for a PKP - smart contract accounts with signing capabilities through PKPs.
4. Non-ECDSA AA wallet with a PKP wallet - allowing freedom of signature verification scheme.
5. Adding a PKP as a signer to an AA wallet - where the PKP is the spending account and the AA wallet is the treasury for a DAO.

1. Conditional Gas Payer

A current issue not solved by ERC4337: Letting existing EOAs send operations that get paid for by third parties.

With PKPS and Lit Actions, we can build a way for an EOA to send an operation - maybe it’s a transaction on chain - and have that gas be covered by a PKP. Imagine we are playing a multi-level game where the underlying game infrastructure needs gas to pay for actions within the game. Once a certain level has been met, a condition can be set where a PKP wallet starts to pay for the gas fees. This can be a built-in reward and incentive mechanism for folks playing the game.

What if a game designer wanted to reward gamers within their ecosystem? They might want to pay the gas transactions for a player who has played a previous game of theirs. Lit Actions can bring in off-chain and cross-chain data into its validation logic.

Pay fees in any token

If a game requires a token that a gamer does not have, obtaining the token can be an inconvenience as they need to make a transfer or trade to obtain the required token. PKPs can be the account specified by the game to pay gas fees using specified tokens, a gamer might only have ETH in their wallet and the game might require gas in MATIC. A PKP delegated as a payer in this situation could hold MATIC specifically for paying for the game transactions. This eliminates the need for users to make additional transactions to obtain the token required, abstracting the underlying gas payment infrastructure away from the gamer.

2. User Onboarding

Account abstraction is a technique that can be used to onboard new users into web3 by leveraging their existing web2 accounts. This approach allows users to authenticate with their web2 account and create an underlying web3 wallet associated with their account, without having to understand the complexities of public key infrastructure and key management.

The user would log in to the wallet using their Google OAuth credentials and the wallet will create a new web3 account associated with their web2 account. The underlying web3 account can be a smart contract account associated with a PKP. This linking of smart contract account -> PKP -> Google OAuth allows for interactions such as multi factor authentication and social recovery.

The PKP has the signing capabilities to allow the user to interact with dApps and smart contracts on the blockchain. This enables the user to extend their existing web2 identity, making the onboarding process seamless and user-friendly.

3. AA Wallet Authorization for a PKP

For most blockchains, smart contracts cannot hold a private key. If you want a smart contract to sign with a PKP, you’ll need an authSig which can be produced via EIP-1271. This enables smart contracts to authorize PKPs to sign on its behalf.

Smart Contract Authsig (EIP1271) | Lit Protocol Developer Docs

You can use the code from the docs to give signing rights to a smart contract. Once that smart contract has an authSig, it can be the method of authorization for a PKP.

One example use case is enabling a smart contract account to have two (or more) factor authentication for web3. We can think of this as a multi-smart contract authentication, creating multiple ways of authorization. Imagine that one of the keys for your account is managed by a service that will only co-sign if you've confirmed with a second factor like email or SMS. If you confirm the second factor, the transaction succeeds. If you don’t, it’s automatically blocked.

This additional layer of security greatly reduces the risk of unauthorized transactions and protects your assets from being stolen by hackers or malicious actors. By requiring the use of a secondary factor, MFA makes it much more difficult for an attacker to access your account, even if they have obtained one method of authorization to sign!

4. Non-ECDSA AA wallet with a PKP (ECDSA) wallet.

An account abstraction wallet enables portable signature verification by allowing users to interact with different blockchain networks using the same set of credentials. This eliminates the need for users to create separate accounts and manage multiple private keys for different networks, making it more convenient and secure to interact with multiple blockchain-based systems. We can also Abstracting the technology and implementation details of how to sign based on different signature schemes.

For example, Fuel’s AA wallet can generate a signature that can be verified through PKPs and Lit Actions. Funds can be sent from Fuel’s AA wallet to a PKP which would execute some transactional logic via Lit Actions.

5. PKP as a Signer on an AA wallet

PKPs can be added as a signer to an AA wallet for multiSigs. A Lit Action will hold the logic for when the PKP should sign.

Imagine there is a DAO that wants to separate a spending account and its treasury. This approach allows a DAO to have a clear separation of funds between the spending account, which is used to make transactions and pay for expenses, and the treasury, which is used to hold and manage the organization's funds.

The treasury is a smart contract account (an AA wallet). The smart contract account acts as a multi-sig wallet, allowing multiple members of the DAO to manage and access the funds in the treasury. The spending account, on the other hand, is controlled by a single member or a group of members, who are responsible for making transactions and paying for expenses. The spending account can be a PKP and a Lit Action will hold the access control conditions and logic for who can authorize the signing rights of the PKP.

Learn more about using PKPs and Lit Actions

Check out these technical posts on how to use Lit for wallet abstraction:

• Connect Your Lit-Powered Cloud Wallet to the Decentralized Web: Developers can use Lit and WalletConnect to seamlessly connect Lit-powered cloud wallets to hundreds of decentralized applications. This integration unlocks unique use cases for programmatic signing and condition-based automation, from DeFi to gaming, ultimately helping users streamline their experiences across the dWeb.
• Wallet Abstraction using Lit and Google OAuth: Follow this guide to understand a proof of concept on how to mint a Programmable Key Pair and execute an on-chain transaction with only a Google account.

Closing

Account abstraction is a powerful concept that is changing the way we interact with blockchain networks. By using smart contract wallets containing arbitrary verification logic instead of traditional EOAs, account abstraction opens up a world of new possibilities for developers and users alike. With the ability to create custom verification logic, users can tailor their account security to their specific needs and preferences. Account abstraction combined with MPC brings in possibilities of off-chain data into verification logic. As blockchain technology continues to evolve, we hope to see more innovative use cases for account abstraction with MPC!

If any of the explorations sparked your interest, Lit has a grants program and the team is looking to fund open-source tooling and novel projects that extend the use of Lit.

Have questions or comments? Ask away in Discord!