ZeroTrust Accounts

A proof of concept by Karandeep Singh and Alexander Chopan

What if you could use a passkey as a signer for your embedded smart contract account and reuse the account across other apps? What does that mean and who cares? Try the demo first, then come back here.

React AppWeb site created using create-react-appt.co

The goal of ZeroTrust Accounts is to provide a decentralized, secure, and self-sovereign approach to Ethereum smart contract accounts. How? With non-custodial signers (like passkeys); inbuilt or modular session keys features; server-free information access; and decentralized recovery options. karandeepsingh.eth and I got to these conclusions by working backwards from user goals to engineering solutions and product experience. Here’s the idea 0-1. This is a long post.

Users
Goals
How accounts work today
Account problems
Solutions
Requirements
Features
Proof of concept
User Journey
Code
Demo

1. Users

Alice is a consumer. She uses many applications. She has over 100 accounts. Bob is a developer. He makes blockchain apps for consumers like Alice.

2. Goals

Alice (consumer): wants to enjoy online and onchain activities with friends, collect digital assets, use decentralized apps easily, control her account in various places, and avoid losing account access or data.

Bob (developer): wants to make user-friendly apps for NFT minting, that don’t require users to interrupt activity to approve actions, and can sponsor gas fees for user operations. He wants to use account abstraction and offer smart accounts for a better user experience.

3. How Accounts Work Today

Offchain In the current web model, there are account users and providers. Users require accounts for online activities. They provide personal data to create accounts. These accounts serve as containers for data and have rules. Users access accounts with keys and passwords. They trust providers to keep data safe.

Onchain: externally-owned accounts The Ethereum blockchain operates on an account model with one native type, the externally owned account (EOA). EOAs are controlled by private keys and operated by the account holder who possesses the private key. They are used for sending/receiving transactions and interacting with applications. EOAs are created when a private key is generated and associated with a public address. They do not require on-chain deployment or initial funding. ETH balance — is required for transactions and gas fees. Security relies on the user's management of private keys, and account recovery is not possible if the keys are lost.

Onchain: smart accounts Smart accounts In Ethereum are smart contract code. The code must be deployed to the blockchain before the user can make their first transaction. This requires some initial funds. Smart accounts have programmable features such as transaction batching, multi-signature management, two-factor authentication (2FA) and account recovery. They allow users to pay for gas fees in any token and even have their transactions sponsored. These smart features make them like mini-apps on the blockchain.

Onchain: embedded accounts Onchain embedded accounts are smart contract accounts embedded in specific dapps, allowing users to perform wallet actions directly within the dapp. These accounts are provided instantly by the dapp, removing the need for users to separately create and set up a blockchain account. Access to these accounts is limited to the dapps they are tied to, streamlining the user experience, especially for newcomers to blockchain technology. To create embedded accounts, Bob tests various SDKs from account providers to select the best one. Bob must get API keys from account providers to use their services. In order to get API keys, Bob must create new accounts for himself. Here let’s explore 2 kinds of embedded accounts Bob wants to create — an EOA and passkey based.

4. Account Problems

Not Secure Dapps connect directly to accounts and users authorize blanket access. Ethereum blockchain requires an EOA to make transaction, and to reuse same signer each time. The smart contract account security depends on EOA security. Alice’s and Bob’s security are dependent on the account types and account provider services they choose.

Low Control Users have limited control over their blockchain accounts as their behavior is hardcoded in the Ethereum protocol. For passkey-embedded accounts, apps store and manage passkey meta details in the account provider's databases, creating a dependency. Alice faces the risk of being locked out of the passkey signer if the dapp domain becomes inaccessible, which affects her ability to use her account and Bob's ability to provide her with an account.

Not Smart Users and developers waste time on account management instead of account activity. Users sign each transaction. New technologies like passkeys and embedded wallets complicate multi-account management. Account types have different functionalities and may not be compatible. Different providers interpret account abstraction differently, making it challenging for Alice and Bob to manage and migrate accounts.

5. Solutions

Create accounts that are safer and smarter by continuously removing layers of trust. Provide a decentralized, secure, and self-sovereign approach to Ethereum smart contract accounts. Use non-custodial signers (like passkeys); inbuilt or modular session keys features; server-free information access; and decentralized recovery options.

6. Engineering Requirements

More secure Ensure a secure method for managing signers, including the use of alternative signers that offer higher security than EOAs. Implement layers of separation between different accounts to enhance security. Create unique sessions each time a dapp connects to an account, with session-specific permissions like time limits, token allowances, and spending limits. Determine these permissions by combining various scopes, which are specific target contracts or methods.

More control Users should have easy access to their accounts and use them as desired, without relying on third-party providers.

Smarter They should also be able to easily create smart contract accounts without complex wallet setup. They shouldn’t have to already have an EOA. Users should be able to use dApps quickly and effortlessly, with uninterrupted and signless transactions. Actions should be automated (e.g., pre-approval, scheduling) so that users do not have to create new accounts every time they want to use a dApp.

7. Features

8. Proof of Concept

9. User Journey

Step 1: Create Account User: The user decides to interact with a dapp through its website with the goal of minting an NFT. The user clicks either "Connect Wallet" or "Sign In with Account Provider." This action redirects the user to a sign-in or sign-up page. Existing users sign in to authorize the dapp to use their Zero Trust account. New users create a unique name for their account, and upon entering this name, the ZeroTrust account becomes "created,” and the user can grant the dapp access to it. -

Under the Hood: We associate a passkey with the user's chosen account name, enhancing security. The metadata related to the passkey is securely stored in the user's browser's local storage. Using this metadata, we derive a counterfactual smart contract wallet address.

Step 2: Authorize Dapp User: The user authorizes the dapp to use the account, by choosing the scope to limit what the dapp can do while the session is active. The user signs the user operation, which records session details on the blockchain for security. -

Under the hood: A sessionID is created which defines the scope for activity. The sessionID is committed onchain by signing a transaction using the passkey. This saves the sessionID onchain.

Step 3: Mint NFT User: The user is redirected to the dapp to interact with the dapp, using the authorized ZeroTrust account. The user clicks "mint" and mints the NFT.

Under the hood: Instead of signing each user operation and being interrupted with signature requests, the user submits a zero-knowledge proof for the operation. All operations occur on the user's device.