Author: Rui, @Ruisnakes

Table of Contents

• Is the crypto user experience terrible? It's the key management that's a mess!

• Key Management Layer: Responsibility, Storage, and Access

• Existing Product Analysis: MetaMask, Trust Wallet, Privy, and Particle

• New Solutions:

• Key Layer: WebAuthn, Secure Enclave, and Passkey

• Account Layer: Smart Contract Account (SCA), External Account (EOA)

• Signature Layer: Protocol r1 Precompiled, Third-party Services, Solidity, and Zero-Knowledge Verifiers

• Case Studies: (Key) + (Account)

• Clave Wallet: (Secure Enclave WebAuthn) + (SCA)

• Soul Wallet: (Passkey) + (4337 SCA)

• OKX Wallet: (MPC-TSS + Passkey) + (4337 SCA)

• Web3 Auth: (MPC-TSS + Passkey) + (EOA/SCA)

• Lit Protocol: (MPC-TSS + Decentralized Nodes + Passkey) + (EOA/SCA)

  *Please note that the above cases may change and improve rapidly.

• Outlook

TL;DR

Private keys are the key to signing transactions on Ethereum, but even managing them in a readable form like mnemonic phrases (also known as "seed phrases") is a nightmare for users. And we know that turning blockchain into a complex game was never our intention.

To ensure transaction security, it is essential to authenticate authorized users. With the development of internet security and user experience, we have evolved from password authentication to biometric technologies like facial recognition and fingerprints. In this progress, WebAuthn is a key milestone. This article will focus on three terms:

• WebAuthn: This is a web authentication standard that uses public key-based credentials typically created by external authenticators. It allows secure user authentication without passwords.

• Secure Enclave: A hardware-based secure area within a computing device designed to protect sensitive data. Different versions of Secure Enclave are available for iOS, Android, and Windows devices. When applying WebAuthn, it can act as an external authenticator, providing hardware-level security, but since the private key is bound locally, this complicates cross-device operations.

• Passkey: An OS-level WebAuthn application, with various device and system providers having their custom rules. For example, Apple's Passkey utilizes keys stored in iCloud Keychain for cross-device synchronization. However, this method typically applies only to specific platforms or systems and does not achieve cross-system compatibility (Apple-Android).

As mentioned above, the deployment of WebAuthn aligns with our goal for everyday blockchain users: to achieve advanced anti-phishing security and a user-friendly experience. Here are proposals for integrating WebAuthn into blockchain:

• Key Layer: Users can authenticate using smooth methods like facial recognition or fingerprints. At the core, it is based on hardware security processors (like Secure Enclave) or cloud services (like iCloud and Google Cloud) for key management. I will delve deeper into cross-device and cross-platform issues later.

• Account Layer: Smart Contract Accounts (SCA) can assign any signer (e.g., SE and Passkey) and threshold mechanisms. Additionally, their modular design enhances flexibility and upgradability. For example, smart contract accounts can dynamically adjust their signing requirements based on factors like transaction volume, time, or IP address. On the other hand, traditional External Accounts (EOA) can be extended through Multi-Party Computation (MPC) services, providing better interoperability and cost-effectiveness compared to smart contract accounts, but lacking the advanced features offered by smart contract accounts, particularly in key rotation, which becomes more challenging.

• Signature Layer: Ethereum natively supports the k1 curve, but the signature verification of WebAuthn incurs higher costs because it uses the r1 curve to generate keys. Therefore, Layer 2 solutions like zkSync plan to adopt native EIP-7212 r1 curve precompiles. Additionally, there are third-party services, Solidity verifiers, zero-knowledge (ZK) verifiers, and distributed key management systems that can facilitate r1 curve signatures in a more cost-effective manner.

*Disclaimer:

Technological advancements do not guarantee market success; not all devices and platforms have adopted Passkey; using smart contract accounts may be more expensive than external accounts; the proposed solutions will evolve with technological advancements.

Is the crypto user experience terrible? It's the key management that's a mess!

In the blockchain space, the true control of blockchain assets does not lie with users or wallet providers, but with private keys. This key determines the success or failure of transaction execution on Ethereum. To better understand this, let's take external accounts as an example:

• Key Generation: A random number selected from the secp 256 k1 elliptic curve serves as the private key. This private key is then multiplied by a predefined point on the curve to generate the public key. The Ethereum address is derived from the last 20 bytes of the hashed public key. Typically, we use mnemonic phrases to convert the private key into human-readable words for backup, ultimately generating the private and public keys.

• Signing Transactions: The private key is used to sign a transaction containing details like nonce (sequence number), amount, gas price, and recipient address. This process involves the Elliptic Curve Digital Signature Algorithm (ECDSA), which uses elliptic curve cryptography and the secp 256 k1 curve to generate a signature composed of (r, s, v) values, which is then broadcasted along with the original transaction to the network.

• Verifying Transactions: Once the transaction reaches an Ethereum node, it is verified in the node's memory pool. To verify the signer, the node uses the signature and hashed transaction to obtain the sender's public key and confirms the transaction's authenticity by matching the extracted address with the sender's address.

As mentioned above, the private key is a crucial entity on-chain. Initially, Ethereum accounts, i.e., external accounts, relied entirely on a single private key, which posed significant risks, as losing the private key means losing access to the account.

Many might think that Account Abstraction (AA) is the ultimate solution to user experience issues, but I would argue otherwise. Account abstraction turns the validity rules on Ethereum into programmable rules, and smart contract accounts enable this realization. Account abstraction is powerful, allowing for the parallel sending of multiple transactions (abstract nonce), gas sponsorship, and support for using ERC 20 to pay gas (abstract gas), with a feature more relevant to this article being that account abstraction can break fixed signature verification (abstract ECDSA signature). Unlike external accounts, smart contract accounts can assign any signer and signing mechanism, such as multi-signatures (multisigs) or scoped keys (session keys). However, despite the increased flexibility and upgradability of account abstraction, transaction signatures still require keys.

Even converting a private key into a 12-word mnemonic phrase, managing private keys remains a significant challenge, with risks of loss or phishing attacks. Users must choose between complex decentralized solutions and centralized services, but neither is ideal.

Why is the crypto experience so terrible? A large part of the reason is that key management is poor. When managing keys, users always need to balance experience, security, and decentralization. This article explores potential best solutions for key management.

Key Management Layer

There is never a one-size-fits-all solution; the best way to manage keys needs to be customized based on specific user scenarios and is influenced by various factors such as user type (institutional or individual), capital amount, transaction frequency, and interaction types.

To clarify in advance, I will not use currently popular terms like "self-custody, semi-custody, and full custody." In my view, true self-custody means not relying on others and independently signing transactions, even if some solutions that are not traditionally considered custodial (like storing in a decentralized node's trusted execution environment) are not non-custodial either. Judging solutions solely based on custody types is overly simplistic and does not account for the applicability differences of these solutions. To evaluate key management methods more thoroughly, I suggest analyzing them through three different dimensions.

Responsibility

Whether the responsibility for key management is divided among different parties.

Since individual users often face various challenges in managing keys, allocating key management responsibilities naturally becomes a risk mitigation strategy. Such methods include using multiple keys for collaborative signing, with multi-signature (Multi-sig) systems being one example, and dividing the private key into multiple parts through secret sharing schemes (SSS) or multi-party computation (MPC).

• Multi-signature (Multi-sig): Requires multiple complete private keys to generate a transaction signature. This method necessitates on-chain communication among different signers, incurs higher transaction fees, and affects privacy since the number of signers is visible on-chain.

• Secret Sharing Scheme (SSS): Generates a private key at a single location, then divides this key into multiple parts distributed to different parties. Each party must reconstruct the complete private key to sign transactions. However, this temporary reconstruction may introduce vulnerabilities.

• MPC-TSS (Threshold Signature Scheme): As an implementation of multi-party computation, this cryptographic method allows multiple parties to compute while keeping their inputs jointly private. Each party independently creates a key fragment without needing to meet in person to sign transactions. Because this is an off-chain operation, it incurs lower costs and avoids the single point of failure risk of secret sharing schemes.

Storage

Storing keys or key fragments, influenced by security, accessibility, cost, and decentralization factors.

• Centralized cloud services, such as AWS, iCloud, etc. This method facilitates frequent transactions but is more susceptible to censorship.

• Decentralized storage like IPFS and Filecoin.

• Local computers/mobile devices: Keys stored in the browser's secure storage.

• Paper wallets: Printing out private keys or QR codes.

• Trusted Execution Environment (TEE): A secure area provided within the main processor, executing or storing sensitive data independently of the main operating system.

• Secure Enclave: The Secure Enclave on modern devices is isolated from the main processor, providing an additional layer of security, ensuring the safety of sensitive user data even when the application processor kernel is compromised.

• Hardware wallets: Physical devices like Ledger and Trezor specifically designed for secure private key storage.

• Hardware Security Modules (HSM): Hardware devices specifically designed for secure key management and cryptographic operations, typically used in enterprise environments, providing high-level security features.

Access

How to verify user identity to access stored keys.

Accessing stored keys requires authentication. This necessitates verifying whether the individual attempting to access is indeed authorized to access the keys. Looking back, access methods can be categorized as follows:

• What you know: Passwords, PIN codes, answers to security questions, or specific patterns.

• What you have: Includes smart cards, hardware tokens (time-based one-time passwords), or digital factors like social account verification and SMS codes sent to phones.

• Who you are: Unique physical characteristics of the user, such as fingerprints, facial recognition (like Apple's Face ID or Windows Hello), voice recognition, or iris/retina scans.

Based on these foundations, two-factor authentication (2FA) and multi-factor authentication (MFA) combine at least two factors, such as pairing SMS with push notifications to enhance user account security.

Existing Product Analysis

MetaMask allows users to access keys stored in local browser storage using a password.

Trust Wallet allows users to access keys stored in their local browser storage using a password or Face ID, and users can also choose to back up their private keys using cloud services.

Privy allows users to log in using various social login methods like email, dividing keys into three parts through a secret sharing scheme:

• Device Fragment: Browser-iFrame, Mobile-Secure Enclave.

• Auth Fragment: Stored by Privy, linked to Privy ID.

• Recovery Fragment: User password or encrypted by Privy and stored in a Hardware Security Module (HSM).

Particle allows users to use social login and employs MPC-TSS to divide keys into two parts:

• Device Fragment: Browser-iFrame

• Server Key Part: Particle's server

New Solutions

Key Layer: WebAuthn, Secure Enclave, and Passkey

The existing solutions mentioned above have played a crucial role in attracting users to Web3. However, challenges have arisen: passwords may be forgotten or become targets of phishing attacks, and while 2FA is more secure, it can be cumbersome due to multiple steps. Additionally, not everyone is willing to entrust key management to third parties, and when some services prevent users from accessing keys, users still rely on the availability and effectiveness of the system.

This leads us to consider whether there is a more effective solution—a solution that can provide near-trustless, high-security, and seamless user experience. The pursuit of such a solution has guided us to optimal Web2 methods. As mentioned at the beginning of this article, several terms are closely related to this topic, with WebAuthn being the authentication standard, while Secure Enclave and Passkey are deployments or components related to that standard.

WebAuthn

WebAuthn specifies the interface for user authentication for web-based applications. Users can log into internet accounts using external authenticators instead of passwords. Authenticators can be roaming authenticators (like Yubikey, Titan key) or platform authenticators (like the built-in keychain on Apple devices).

The technology behind WebAuthn was initially developed by the FIDO (Fast IDentity Online) Alliance. In March 2019, W3C officially announced WebAuthn as a web standard, and as its standardization progressed, major browsers like Google Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari adopted WebAuthn, significantly expanding its application scope and availability. It is now supported by many advanced devices.

Advantages of WebAuthn:

• Higher Security: Reduces the risk of phishing, brute force, and replay attacks by eliminating reliance on passwords.

• Improved User Experience: Provides simpler and faster logins, often requiring just a click or biometric verification to log in.

• Privacy Protection: No shared secret content is transmitted during the authentication process, and individual websites do not receive any personal identification information.

• Scalability and Standardization: As a web standard, WebAuthn ensures consistency and interoperability across different browsers and platforms.

Device-based WebAuthn, such as Secure Enclave

Now, we can use hardware processors as authenticators, such as Secure Enclave on Apple devices, Trustzone on Android devices, and Strongbox on Google Pixel.

• Key Generation: Using public key cryptography, key pairs are generated according to the WebAuthn standard, typically using the P-256 r1 curve. The public key is sent to the server, while the private key never leaves the Secure Enclave. Users never handle plaintext keys, ensuring the security of the private key.

• Key Storage: The private key is securely stored within the device's Secure Enclave, a hardened subsystem isolated from the main processor. It protects sensitive data, ensuring that even if the main system is compromised, the original key material remains inaccessible. The barrier to breaking into the Secure Enclave is very high, which is why the most sensitive data types (like Apple Pay and FaceID data) are stored here. Here is a detailed explanation of how Secure Enclave works.

• Authentication: Users gain access using facial recognition or fingerprints, and the Secure Enclave signs the server's challenge using the private key, while the server verifies it using the public key.

Advantages of device-based WebAuthn:

• Hardware-level Security: A hardware-based key manager like Secure Enclave enhances security.

• Resistance to Phishing Attacks: Do not enter any information on devices or websites that may be compromised.

• Convenient Experience: Provides a more user-friendly experience. Users no longer need to remember complex passwords for different websites.

Disadvantages of device-based WebAuthn:

• Device Limitations: If the device is lost or damaged, the private key cannot be exported or retrieved, making cross-device operations impossible.

Cloud-based WebAuthn, Passkey

To address the challenges of cross-device functionality, tech giants have introduced cloud-based WebAuthn deployments, with Passkey being widely known due to Apple.

Taking Apple's Passkey as an example:

• Key Generation: The user's macOS, iOS, or iPadOS device acts as the authenticator, generating a public key and private key when the user creates an account. The public key is sent to the server, while the private key is stored in the device's iCloud Keychain. The iCloud Keychain data is encrypted with a hardware-bound key pair and stored in a hardware security module. Apple cannot access this key pair.

• Cross-device Synchronization: This process is similar to accessing iCloud. Authenticate the iCloud account, receive an SMS verification code, and then enter the password for one of the devices.

Advantages of cloud-based WebAuthn:

• Cross-device: Passkey is designed for user convenience, allowing access across all frequently used devices. However, it is currently limited to Apple devices. This method poses greater challenges for Android devices due to the variety of versions and hardware.

• Phishing Attack Resistance: Same as above.

• Convenient Experience: Same as above.

Disadvantages of cloud-based Passkey:

• Reliance on Cloud Services: Compared to device-based WebAuthn, cloud-based Passkey shifts the security layer from the hardware of Secure Enclave to iCloud Keychain, which some may consider as being hosted on cloud services. Key points to consider include whether the user's iCloud Apple ID account has been compromised; although iCloud Keychain uses end-to-end encryption to protect data, operational errors or vulnerabilities can pose risks.

• Platform Limitations: For example, using iCloud-based passwords on Android devices is highly challenging. Additionally, unlike traditional methods, Apple and Google do not send device-specific assertions. This means that it is currently impossible to verify the type of device that generated the key, raising questions about the reliability of the keys and their associated metadata.

Account Layer: Smart Contract Accounts and External Accounts

So far, we can see that maintaining hardware security while solving cross-device and cross-platform compatibility is a significant challenge. Equally important are social recovery options, such as adding multiple guardians to enhance security. In this case, blockchain can point us in the right direction.

Please note: When we attempt to deploy Web2's WebAuthn to Web3, a clear difference is that Web2 only needs to prove ownership, while Web3 also requires transaction authorization simultaneously. If one only has a Passkey, developers cannot control the signed message, which is usually generic, like "sign in." This could lead to potential frontend manipulation issues, where users "blindly" sign messages—this issue may seem trivial but is crucial.

Smart contract accounts are themselves smart contracts, serving as on-chain entities that can specify any signer. This flexibility allows users to set up various devices and platforms, such as designating an Android phone, Macbook, and iPhone as signers. Additionally, modular smart contract accounts support upgrades, allowing for the exchange of new signers and changing the signing threshold from 2/3 to more complex configurations.

Imagine a wallet that can flexibly adjust its security requirements based on circumstances: when the user is on a familiar local IP address, this wallet supports single-signer authentication, but requires multiple signers for transactions from unknown IP addresses or exceeding a certain value. With modularity and programmability, only innovations we cannot imagine remain unachieved. Many smart contract account service providers are actively building in this space, including Safe, Zerodev, Biconomy, Etherspots, Rhinestone, etc. Thanks to infrastructure providers like Stackup, Plimico, and Alchemy, all of this is made possible.

Please check my previous research for a more comprehensive background on smart contract accounts.

Smart contract accounts can achieve social recovery and cross-device/platform compatibility through multi-party computation services. Although smart contract accounts have fixed signers, multi-party computation providers can split keys into multiple parts to enhance security and flexibility. This approach lacks the programmability and upgradability features of smart contract accounts, such as time-lock recovery and easy key deactivation. However, MPC is not limited to specific blockchains, thus offering superior cross-chain capabilities and being more cost-effective than smart contract accounts. Notable multi-party computation providers include Particle Network, Privy, web3 Auth, OKX Wallet, Binance Wallet, etc.

Signature Layer: R1 Support

Let’s take a step back to understand: on Ethereum, private keys are random numbers selected from the k1 curve, and the signing process also utilizes this curve.

However, the key pairs generated according to the WebAuthn standard use the r1 curve. Therefore, the cost of verifying r1 signatures on Ethereum is about three times that of k1 signatures. Here are solutions to this issue:

Thanks to Dogan's contributions, please check his research for deeper insights.

Protocol Solutions:

• Solution: EIP 7212, precompiled support for secp 256 r1 curve, proposed by the Clave team.

• Assessment: This proposal creates a precompiled contract that executes signature verification in the "secp 256 r1" elliptic curve using the given message hash, signature's r and s, and the public key's x and y coordinate parameters. Thus, any EVM chain (mainly Ethereum's Rollups) can easily integrate this precompiled contract. So far, protocol precompiles may be the most gas-efficient solution.

• Application: zkSync

Third-party Services:

• Solution: Turnkey

• Assessment: Turnkey TEE ensures that the private key can only be accessed by the user through their Passkey, and Turnkey can never access the private key; however, this still requires the service's effectiveness.

• Implementation: Goldfinch

Solidity Verifier Solutions:

• Solution: FCL's Solidity Verifier, FCL with pre-computed Solidity Verifier, Daimo's P 256 Verifier

• Implementation: Clave, Obvious Wallet

Zero-Knowledge (ZK) Verifiers:

• Solution: Risc Zero's Bonsai, Axiom's halo 2-ecc

• Assessment: This approach utilizes zero-knowledge proofs to verify computations outside the Ethereum Virtual Machine (EVM), reducing on-chain computation costs.

• Implementation: Bonfire Wallet (Risc Zero), Know Nothing Labs (Axiom)

These solutions can achieve cheaper and more feasible r1 signature verification within the Ethereum ecosystem, as assessed by Dogan.

New Case Studies for WebAuthn

*Please note that as of December 2023, most of these solutions are in early stages and may change or improve at any time. These examples are for educational purposes only; always refer to their official websites for accurate information.

Clave Wallet: (Secure Enclave WebAuthn) + (Smart Contract Account)

Basic Information:

• Demo: https://getclave.io/

• Account: Smart Contract Account

• Chain: ZkSync

Transaction Process:

• Key Creation: Users perform biometric verification, such as fingerprints or facial recognition, generating key pairs within the Secure Enclave, which are never exposed.

• Key Signing: The application receives the required transaction message and forwards the signing request to the Secure Enclave, where the user performs biometric verification to approve the signature. The Secure Enclave signs the message with the key and then broadcasts it to the blockchain node.

• Additional Features: Smart contract accounts support many powerful features. First is gas sponsorship. Using Paymaster, dApps or advertisers can pay gas for users, making the transaction process smoother, while also allowing users to pay gas with ERC 20 tokens instead of only Ether or native tokens. Additionally, users can use session keys for transactions without signatures for a period.

Recovery Mechanism:

• The recovery process is handled by Clave's smart contract on zkSync, allowing users to cancel recovery within a 48-hour lock period to prevent unauthorized malicious activities.

• Cloud Backup: When users choose cloud backup, an external account is created, with the private key stored in iCloud or Google Drive. Users can access their accounts from different devices using the cloud-stored private key and can delete or overwrite this backup at any time.

• Social Recovery: Users can designate Clave addresses of family or friends as backups. If M out of N guardians confirm the recovery and it is not canceled, the recovery will be executed after the 48-hour lock period.

Soul Wallet: (Passkey) + (4337 SCA)

Basic Information:

• Demo: https://alpha.soulwallet.io/wallet

• Account: ERC 4337 Smart Contract Account

• Chain: Ethereum, Optimism, Arbitrum, soon to fully support Ethereum Virtual Machine Layer 2

Transaction Process:

• Key Creation: Users provide biometric verification like fingerprints or facial recognition, and the operating system generates a Passkey, backed up using cloud services. Users can add multiple Passkeys across devices and platforms.

• Adding Guardians (Optional): Users can specify different Ethereum Virtual Machine external account addresses as guardians and set account recovery thresholds.

• Account Generation: Using counterfactual deployment, users do not need to pay any fees before their first transaction.

Recovery Mechanism:

• Passkey: Log into the wallet using any defined Passkey on any device.

• Guardian Recovery: Designated guardians can rotate the wallet based on thresholds, with time locks set later to prevent malicious actions.

OKX Wallet: (MPC-TSS + Passkey) + (4337 Smart Contract External Account)

Basic Information:

• Demo: https://www.okx.com/help/what-is-an-aa-smart-contract-wallet

• Chain: 30+ chains

• Key: MPC-TSS, 2/3

• Account: 4337 Smart Contract Account

Transaction Process:

• Key Creation: By creating a wallet, OKX divides a single private key into three separate parts. One part is stored on OKX's server, one part is stored in the user's device's local storage, and another part is generated by the device, encrypted, and can be backed up to the user's preferred cloud service, such as Google Cloud, iCloud, and Huawei Cloud.

• Key Signing: OKX uses MPC-TSS technology, allowing users to obtain a complete signature by using two of the three private key parts when signing a transaction, during which the private key fragments do not touch each other.

Recovery Mechanism:

• 2/3 Mechanism: When a user logs out, the device is unavailable, or one of the keys on the device is compromised, the user can log into the OKX wallet using a new device (accessing the server-stored key) and retrieve the cloud-stored key part, using these two key parts to recover the wallet. The OKX wallet will generate a new key part.

Web3 Auth: (MPC-TSS + Passkey) + (External Account/Smart Contract Account)

Basic Information:

• Demo: https://w3a.link/passkeysDemo

• Chain: All EVM and Solana

• Key: MPC-TSS, typically 2/3

• Account: Any account, including external accounts, 4337 smart contract accounts, or universal smart contract accounts.

Transaction Process:

• Key Creation: By creating a wallet, three key parts are generated. One part is for social login, where users can enter their email, and decentralized network nodes store each user's key; one part is the key stored in the user's device's local storage; and another part is generated by the local computer and backed up by the user's preferred cloud service.

• Key Signing: The Web3 Auth MPC-TSS architecture ensures that users' keys are always available, and even with threshold signatures, the keys are never reconstructed or stored in a single location.

Recovery Mechanism:

• Threshold Recovery: When a user logs out, the device is unavailable, or a key on the device is compromised, the user can log into the WebAuthn account using social login methods and retrieve the cloud-stored key part, using these two key parts to recover the wallet.

Lit Protocol (MPC-TSS + Decentralized Nodes + Passkey) + (External Account/Smart Contract Account)

Basic Information:

• Demo: https://lit-pkp-auth-demo.vercel.app/

• Chain: Most EVM, Cosmos, Solana.

• Account: MPC-TSS, 2/3 mechanism, applicable to both smart contract accounts and external accounts.

Transaction Process:

• Key Creation: When a user wants to create a wallet, they first choose an authentication method (supporting Passkey, oAuth social login), then send a request to the relayer to create key pairs, storing the authentication logic in a smart contract. Each key pair is jointly generated by Lit nodes through a distributed key generation (DKG) process. As a decentralized network, TEE runs 30 Lit nodes, each holding a part of the key, but the private key never fully exists within the TEE.

• Key Signing: Upon receiving the request, Lit nodes independently verify or reject the request based on the specified authentication method, and using MPC-TSS technology, generate a signature when more than the threshold (20 out of 30 nodes confirm) is reached, which is then combined by the client to fulfill the request.

Recovery Mechanism:

• 2/3 Mechanism: Access the account using the authentication method stored in the smart contract, where Lit nodes verify the request, and if more than 2/3 of the nodes confirm, the request will proceed.

Outlook

With the strong push of Layer 2, Layer 3, and Data Availability (DA) solutions, we strive to improve blockchain performance. At the same time, we combine zero-knowledge proof privacy with transparency, pursuing true security. All efforts are directed toward the same goal: preparing cryptographic technology for application in users' daily lives.

It is easy to get trapped in an ideal technological dream, but we must ask ourselves: what kind of experience are we pursuing? We envision a world where cryptocurrency should be intuitive and understandable, not intimidating with technical jargon; in this world, users can effortlessly jump down the rabbit hole.

Imagine a user named Rui: she discovers a fantastic dApp that allows easy registration using facial recognition or fingerprints and can set up backups or guardians. She can easily execute transactions with the dApp, possibly paying only a small ERC 20 fee, or perhaps not needing to pay any fee at all. Afterwards, she can customize wallet settings, such as activating time locks for automatic transactions, adding another device as a backup signer, or modifying her guardian list.

Entrepreneurs are working hard to make all of this a reality. By combining WebAuthn and Passkey, we enhance private key management, making it both secure and convenient. On this foundation, smart contract accounts as entities open up realms of personalized security and functionality. As for gas? With Paymaster, providers can create a "treasury" for swap transactions, even allowing advertisers to pay fees for users, so gas is no longer a burden. The core of this evolution, especially for the Ethereum mainnet and its equivalent Layer 2, is ERC 4337. ERC 4337 introduces another memory pool, distinguishing smart contract account transactions from external account transactions without requiring significant modifications to the protocol. On the other hand, some Layer 2 networks even natively adopt smart contract accounts and seamlessly integrate them into the system.

Making everything simple requires tremendous effort. We still face many challenges, such as reducing the deployment, verification, and execution costs of smart contract accounts; standardizing interfaces to enhance account interoperability; and synchronizing account states across chains. Thanks to all the builders, every day we get closer to success. Our company SevenX, along with other crypto startups, is ready to empower great companies and help them realize their visions.

If you are interested in this article, feel free to check out my other articles for a more comprehensive background:

04/ Accounts: Modular Smart Contract Account Architecture and Challenges

03/ Keys (this article): WebAuthn and Passkey, Key Management for Everyday Crypto Users

02/ Infrastructure: The Evolution of Ethereum Accounts Brought by ERC 4337