Author: Rui, @Ruisnakes

Table of Contents

• Is the encryption user experience terrible? It's because the key management is terrible!

• Key Management Layer: Responsibility, Storage, and Access

• Analysis of Existing Products: 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 Precompile, Third-party Services, Solidity, and Zero-knowledge Verifier

• Case Studies: (Key) + (Account)

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

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

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

  - Web3Auth: (MPC-TSS + Passkey) + (EOA/SCA)

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

  *Please note that the above cases may change and improve quickly

• Outlook

TL;DR

The private key is crucial for signing transactions on Ethereum, but even managing the private key in a readable form like a mnemonic phrase is a nightmare for users. We understand that turning blockchain into a complex game has never been our intention.

To ensure transaction security, it is necessary to authenticate authorized users. With the development of internet security and user experience, we have progressed from password authentication to biometric recognition technologies such as facial recognition and fingerprint recognition. 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 enables 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 applied with WebAuthn, it can act as an external authenticator, providing hardware-level security, but local binding of private keys makes cross-device operations difficult.

• Passkey: A webAuthn application at the operating system level, with custom rules from various device and system providers. For example, Apple's Passkey uses keys stored in the iCloud Keychain for cross-device synchronization. However, this method is usually only applicable to specific platforms or systems and cannot achieve cross-system (Apple-Android) functionality.

As mentioned above, the deployment of WebAuthn is consistent with our goal for everyday blockchain users, which is to achieve advanced anti-phishing security and user-friendly experience. The following are proposals for integrating WebAuthn implementation into blockchain:

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

• Account Layer: Smart Contract Accounts (SCA) can allocate arbitrary signers (e.g., SE and Passkey) and threshold mechanisms. Furthermore, its modular design enhances flexibility and upgradability. For example, smart contract accounts can dynamically adjust their signature requirements based on factors such as transaction count, time, or IP address. On the other hand, traditional external accounts (EOA) can be extended through multi-party computation (MPC) services, which provide better interoperability and cost-effectiveness compared to smart contract accounts, but do not offer the advanced features of smart contract accounts, especially making key rotation more challenging.

• Signature Layer: Ethereum natively supports the k1 curve, but WebAuthn's signature verification incurs higher costs because it uses the r1 curve to generate keys. Therefore, Layer 2 solutions like zkSync plan to adopt the native EIP-7212 r1 curve precompile. 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 progress does not necessarily guarantee success in the market; not all devices and platforms adopt Passkey; using smart contract accounts may be more expensive than external accounts; the proposed solutions will continue to evolve with technological advancements.

Is the encryption user experience terrible? It's because the key management is terrible!

In the blockchain field, the true control of blockchain assets does not lie with users or wallet providers, but with the private key. This key determines the success or failure of transactions executed on Ethereum. To better understand this, let's take an example of an external account:

• Key Generation: A random number selected from the secp256k1 elliptic curve is used as the private key. This private key is then multiplied by a predefined point on the curve to generate a public key. The Ethereum address is derived from the hashed public key's last 20 bytes. Typically, we use a mnemonic phrase to back up the private key into human-readable words, ultimately generating the private key and public key.

• Transaction Signing: The private key is used to sign a transaction containing details such as 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 secp256k1 curve to generate a signature composed of (r, s, v) values, which is then broadcast along with the original transaction to the network.

• Transaction Verification: Once the transaction reaches an Ethereum node, it is validated in the node's memory pool. To verify the signer, the node uses the signature and the 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 the chain. Initially, Ethereum accounts, i.e., external accounts, relied entirely on a single private key, posing significant risks because losing the private key means losing access to the account.

Many people may think that Account Abstraction (AA) is the ultimate solution to user experience issues, but I would argue that it is not necessarily the case. Account Abstraction turns the validity rules on Ethereum into programmable rules, which are implemented by smart contract accounts. Account Abstraction is powerful and can enable parallel sending of multiple transactions (abstract nonce), gas sponsorship, support for paying gas with ERC20 tokens (abstract gas), and a feature more relevant to this article - Account Abstraction can break fixed signature verification (abstract ECDSA signature). Unlike external accounts, smart contract accounts can allocate arbitrary signers and signature mechanisms, such as multi-signatures (multisigs) or limited-range keys (session keys). However, despite the increased flexibility and upgradability of Account Abstraction, transaction signing still requires keys.

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

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

Key Management Layer

There is never a foolproof way to manage keys, and the best way to store keys needs to be customized based on specific user scenarios and influenced by various factors such as user type (institutional or individual), capital amount, transaction frequency, and interaction type.

First of all, I want to clarify that I will not use popular terms like "self-custody, semi-custody, and full custody." In my view, true self-custody means not relying on other parties and independently signing transactions, even if some solutions in the traditional sense are not considered custody (such as storing in a trusted execution environment in a decentralized node), they are not non-custodial. Judging the quality of a solution based solely on custody type is too simplistic and does not consider the differences in applicability. To evaluate key management methods more carefully, I suggest analyzing them through three different dimensions.

Responsibility

Whether to allocate the responsibility of key management to different parties.

Since individual users typically face various challenges in managing keys, allocating key management responsibility naturally becomes a risk mitigation strategy. These methods include using multiple keys for collaborative signing, with multi-signature (Multi-sig) systems being an example, and splitting 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 transaction signatures. This method requires communication between different signers on-chain, resulting in higher transaction fees and privacy implications, as the number of signers is visible on-chain.

• Secret Sharing Scheme (SSS): Generates a private key in a single location, then splits this key into multiple parts distributed to different parties. The parties 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 encryption method allows multiple parties to perform calculations while keeping their inputs privately shared. Each party independently creates a key fragment and can sign transactions without the need to physically meet. Because it is an off-chain operation, this method has lower costs and no single point of failure risk like secret sharing schemes.

Storage

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

• Centralized cloud services, such as AWS, iCloud, and other servers. This method is convenient for frequent transactions but is more susceptible to audits.

• Decentralized storage such as IPFS and Filecoin.

• Local computer/mobile device: Keys stored in the browser's secure storage.

• Paper wallet: Printing out the private key or QR code.

• Trusted Execution Environment (TEE): Provides a secure area 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 to ensure the safety of sensitive user data even if the application processor kernel is compromised.

• Hardware wallets: Physical devices such as Ledger and Trezor specifically designed for secure storage of private keys.

• Hardware Security Module (HSM): A hardware device specifically used for secure key management and encryption operations, typically used in enterprise environments and providing advanced security features.

Access

How to verify the user's identity to access stored keys.

Accessing stored keys requires identity verification. This involves verifying that the individual attempting to access the keys is indeed authorized to access them. Looking back, access methods can be categorized as follows:

• Something you know: Passwords, PIN codes, answers to security questions, or specific graphics.

• Something you have: Including smart cards, hardware tokens (time-based one-time passwords), or digital factors such as social account verification and SMS codes sent to a mobile phone.

• Something you are: The user's unique physical characteristics, such as fingerprints, facial recognition (such as Apple's Face ID or Windows Hello), voice recognition, or iris/retina scans.

Building on these, two-factor authentication (2FA) and multi-factor authentication (MFA) combine at least two factors, such as combining SMS with push notifications, to enhance the security of user accounts.

Analysis of Existing Products

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

Trust Wallet allows users to access keys stored in the user's 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 use various social login methods such as email and splits the key into three parts using a secret sharing scheme:

• Device Shard: Browser-iFrame, Mobile-Secure Enclave.
• Auth Shard: Stored by Privy, linked to Privy ID.
• Recovery Shard: 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 split the key into two parts:

• Device Shard: Browser-iFrame
• Server Key Shard: Particle's server

New Solutions

Key Layer: WebAuthn, Secure Enclave, and Passkey

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

This leads us to consider whether there is a more effective solution - one that can provide near-zero trust, high security, and seamless user experience. The pursuit of such a solution led us to find the best Web2 methods. As mentioned at the beginning of this article, several terms closely related to this topic, WebAuthn is an authentication standard, and Secure Enclave and Passkey are deployments or components related to this standard.

WebAuthn

WebAuthn standardizes the interface for user authentication in web-based applications. Users can log in to internet accounts using external authenticators instead of passwords. Authenticators can be roaming authenticators (such as Yubikey, Titan key) or platform authenticators (such as 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 with its standardization, major browsers such as Google Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari have adopted WebAuthn, significantly expanding its application scope and availability. It is now supported by many advanced devices.

Advantages of WebAuthn:

• Higher Security: No longer reliant on passwords, reducing the risk of phishing, brute force attacks, and replay attacks.
• Improved User Experience: Provides simpler, faster logins, usually requiring just one click or biometric verification to log in.
• Privacy Protection: Does not transmit shared secret content during authentication, and individual websites do not receive any personal identity information.
• Scalability and Standardization: As a web standard, WebAuthn ensures consistency and interoperability between different browsers and platforms.

Device-based WebAuthn, such as Secure Enclave

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

• Key Generation: Using public key encryption, a key pair is 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 in the device's Secure Enclave, an enhanced subsystem isolated from the main processor. It protects sensitive data, and even if the main system is compromised, the original key material cannot be accessed. The threshold for breaking into the Secure Enclave is very high, so the most sensitive data types (such as Apple Pay and Face ID data) are stored here. You can find a detailed explanation of how the Secure Enclave works here.
• Authentication: Users gain access using facial recognition or fingerprint, and the Secure Enclave signs the server's challenge with the private key, which the server then verifies using the public key.

Advantages of Device-based WebAuthn:

• Comparable Hardware Security: Secure Enclave, an independent hardware-based key manager, enhances security.
• Resistance to Phishing Attacks: Avoid entering 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 Limitation: If the device is lost or damaged, the private key cannot be exported or retrieved, and cross-device operations cannot be performed.

Cloud-based WebAuthn, Passkey

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

Using Apple's Passkey as an example:

• Key Generation: The user's macOS, iOS, or iPadOS device acts as an authenticator and generates a public and private key when the user creates an account. The public key is then 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 Sync: This process is similar to accessing iCloud. Authenticate the iCloud account, receive a text message verification code, and then enter the password on one of the devices.

Advantages of Cloud-based WebAuthn:

• Cross-Device: Passkey is designed to provide convenient access to users on all frequently used devices. However, it is currently limited to Apple devices. This approach is more challenging for Android devices due to the variety of Android versions and hardware types.
• Protection Against Phishing Attacks: Same as above.
• Convenient Experience: Same as above.

Disadvantages of Cloud-based Passkey:

• Dependency on Cloud Services: Compared to device-based WebAuthn, cloud-based Passkey shifts the security layer from the Secure Enclave's hardware to the iCloud Keychain, which some may perceive as being hosted on a cloud service. Some key points to consider include whether the user's iCloud Apple ID account has been compromised, and the risk of operational errors or vulnerabilities despite the end-to-end encryption of the iCloud Keychain data.
• Platform Limitations: Using an iCloud-based Passkey on Android devices is extremely challenging. Additionally, unlike traditional methods, Apple and Google do not send device-specific assertions. This means that the device type that generated the key cannot currently be verified, raising doubts about the reliability of the key and its related metadata.

Account Layer: Smart Contract Accounts and External Accounts

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

Note: When we try to deploy Web2's WebAuthn to Web3, a significant difference is that Web2 only needs to prove ownership, while Web3 also needs to authorize transactions. If only Passkey is owned, developers cannot control the signing message, which is usually generic, such as "sign in." This could lead to potential front-end manipulation issues, where users blindly sign messages - a seemingly trivial issue but crucial.

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

Imagine a wallet that can flexibly adjust its security requirements based on the situation: when the user is on a familiar local IP address, the wallet supports single-signer authentication, but for transactions from unknown IP addresses or above a certain value, multiple signers are required. With modularity and programmability, there is no innovation that we cannot imagine or achieve. Many smart contract account service providers are actively building in this area, including Safe, Zerodev, Biconomy, Etherspots, Rhinestone, and others. Also, infrastructure providers like Stackup, Pimlico, Alchemy, make all of this possible.

Please refer to 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. While smart contract accounts have fixed signers, MPC providers can split the key into multiple parts to enhance security and flexibility. This approach lacks the programmable and upgradeable features of smart contract accounts, such as time-lock recovery and easy key disablement. However, MPC is not limited to a specific blockchain, making it more cost-effective and having excellent cross-chain capabilities compared to smart contract accounts. Notable MPC providers include Particle Network, Privy, web3Auth, OKX Wallet, BinanceWallet, and others.

Signature Layer: R1 Support

Let's take a step back to understand: on Ethereum, the private key is a random number 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 approximately three times that of k1 signatures. Here are the solutions to this problem:

Thanks to Dogan for his contribution, please refer to his research for a deeper understanding.

Protocol Solutions:

• Solution: EIP7212, precompile support for the secp256r1 curve, proposed by the Clave team.
• Evaluation: This proposal creates a precompiled contract that performs signature verification on the "secp256r1" elliptic curve using the given message hash, signature's r and s, and the public key's x and y coordinates. Therefore, any EVM chain (mainly Ethereum's Rollups) can easily integrate this precompiled contract. So far, the protocol precompile may be the most gas-efficient solution.
• Application: zkSync

Third-Party Services:

• Solution: Turnkey
• Evaluation: 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, but this still requires the effectiveness of the service.
• Implementation: Goldfinch

Solidity Verifier Solutions:

• Solution: FCL's Solidity Verifier, FCL with precomputed Solidity Verifier, Daimo's P256 Verifier
• Implementation: Clave, Obvious Wallet

Zero-Knowledge (ZK) Verifiers:

• Solution: RiscZero's Bonsai, Axiom's halo2-ecc
• Evaluation: This approach uses zero-knowledge proofs to verify computations outside the Ethereum Virtual Machine (EVM), reducing on-chain computation costs.
• Implementation: BonfireWallet (Risc Zero), KnowNothingLabs (Axiom)

These solutions can all achieve cheaper and more feasible r1 signature verification in the Ethereum ecosystem. Here is Dogan's evaluation.

New Case Studies of WebAuthn

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

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

Basic Information:

• Demo: Clave Wallet
• Account: Smart Contract Account
• Chain: ZkSync

Transaction Process:

• Key Creation: User undergoes biometric verification, such as fingerprint or facial recognition, to generate a key pair in the Secure Enclave, which is never disclosed.
• Key Signing: The application receives the required transaction message and forwards the signature request to the Secure Enclave. The user undergoes biometric verification to approve the signature, and the Secure Enclave signs the message with the key pair and broadcasts it to the blockchain nodes.
• Additional Features: The smart contract account supports many powerful features. First is gas sponsorship. Using Paymaster, dApps, or advertisers can pay gas for users, making the transaction process smoother. It also allows users to pay gas with ERC20 tokens instead of only using Ether or native tokens. Additionally, users can use session keys for transactions without the need for signatures within a certain period.

Recovery Mechanism:

• The recovery process is handled by Clave's smart contract on zkSync, and users can cancel the recovery within a 48-hour lockup period to prevent unauthorized malicious activity.
• Cloud Backup: When users choose cloud backup, an external account is created, and the private key of this external account is stored in iCloud or Google Drive. Users can access their account from different devices using the private key stored in the cloud and can also delete or overwrite this backup at any time.
• Social Recovery: Users can specify the Clave addresses of their family or friends as guardians. If M out of N guardians confirm the recovery and it is not canceled after the 48-hour lockup period, the recovery is executed.

Soul Wallet: (Passkey) + (ERC4337 SCA)

Basic Information:

• Demo: Soul Wallet
• Account: ERC4337 Smart Contract Account
• Chain: Ethereum, Optimism, Arbitrum, soon to fully support Ethereum Virtual Machine Layer 2

Transaction Process:

• Key Creation: Users provide biometric verification such as fingerprint or facial recognition, the operating system generates a Passkey, and it is backed up using cloud services. Users can add multiple Passkeys across devices and platforms.
• Adding Guardians (Optional): Users can specify different external account addresses on the Ethereum Virtual Machine as guardians and set the account recovery threshold.
• Account Generation: Utilizing retroactive deployment, users do not need to pay any fees before their first transaction.

Recovery Mechanism:

• Passkey: Log in to the wallet on any device using a user-defined Passkey.
• Guardian Recovery: Specified guardians can rotate the wallet based on a threshold and set a time lock later to prevent malicious behavior.

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

Basic Information:

• Demo: What is an AA Smart Contract Wallet
• Chains: 30+ chains
• Key: MPC-TSS, 2/3
• Account: 4337 Smart Contract Account

Transaction Process:

• Key Creation: When creating a wallet, OKX divides a single private key into three separate parts. One part is stored on the OKX server, one part is stored in the local storage of the user's device, and one 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 this process, the private key fragments do not come into contact with each other.

Recovery Mechanism:

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

Web3Auth: (MPC-TSS + Passkey) + (External Account/4337 Smart Contract Account)

Basic Information:

• Demo: Passkeys Demo
• Chains: All EVM and Solana
• Key: MPC-TSS, typically 2/3
• Account: External Account, 4337 Smart Contract Account, or any general smart contract account

Transaction Process:

• Key Creation: When creating a wallet, three key parts are generated. One part is used for social login, with each user's key stored on decentralized network nodes. Another part is stored in the local storage of the user's device. The third part is generated by the local computer and backed up by the user's preferred cloud service.
• Key Signing: The Web3Auth MPC-TSS architecture ensures that the user's key is always available. Even with threshold signatures, the key is never reconstructed or stored in a single location.

Recovery Mechanism:

• Threshold Recovery: When a user logs out, the device becomes unavailable, or one of the keys on the device is compromised, the user can log in to the WebAuthn account using the social login method and retrieve the key part stored in the cloud. Using these two key parts, the user can recover the wallet.

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

Basic Information:

• Demo: Lit PKP Auth Demo
• Chains: Most EVM, Cosmos, Solana
• Account: MPC-TSS, 2/3 mechanism, applicable to both smart contract accounts and external accounts simultaneously

Transaction Process:

• Key Creation: When a user wants to create a wallet, they first choose an authentication method (supporting Passkey, oAuth social login) and then send the request to a relay to create a key pair and store 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, 30 Lit nodes run internally in a TEE, with each node holding a part of the key, but the private key never exists in full within the TEE.
• Key Signing: Upon receiving a request, Lit nodes independently verify or reject the request based on the specified authentication method. Using MPC-TSS technology, a signature is generated when the threshold (20 confirmations out of 30 nodes) is met, and it is 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, Lit nodes verify the request, and if more than 2/3 of the nodes confirm, the request proceeds.

Outlook

With the strong push for Layer2, Layer3, and Data Availability (DA) solutions, we strive to improve blockchain performance. At the same time, we combine zero-knowledge proof privacy with transparency, aiming for true security. All efforts are directed towards the same goal: preparing encryption technology for everyday use by users.

It's easy to get caught up in an idealistic technological dream, but we must ask ourselves: what kind of experience are we pursuing? We envision a world where cryptocurrencies should be intuitive and understandable, not daunting technical terms; a world where users can effortlessly dive down the rabbit hole without any hassle.

Imagine a user named Rui: she discovers a great dApp that allows easy registration using facial recognition or fingerprint, with the option to set up backups or guardians. She can easily execute transactions using the dApp, perhaps paying a small ERC20 fee or even no fee at all. Afterwards, she can customize wallet settings, such as activating a time lock for automatic transactions, adding another device as a backup signer, or modifying her list of guardians.

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 an entity open up the realm of personalized security and functionality. As for gas? With Paymaster, providers can create a "treasury" for swap transactions and even allow advertisers to pay fees for users, making gas no longer a burden. At the core of this evolution, especially for the Ethereum mainnet and its equivalent Layer2, is ERC4337. ERC4337 introduces another memory pool, distinguishing smart contract account transactions from external account transactions without major protocol modifications. On the other hand, some Layer2 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 state across chains. Thanks to all the builders, every day we are one step closer to success. Our company, SevenX, and other crypto startups are ready to empower great companies and help them achieve their vision.

If you are interested in this article, feel free to explore my other articles for a more comprehensive background information.

04/ Account: Modular Smart Contract Account Architecture and Challenges

03/ Key (This Article): WebAuthn and Passkey, Key Management for Everyday Encryption Users

02/ Infrastructure: The Evolution of Ethereum Accounts with ERC4337

Acknowledgments:

Thanks to my dearest friends for reviewing this article:

David Sneider, Co-founder of Lit Protocol

Henri Stern, Co-founder of Privy

Zhen, Co-founder of Web3 Auth

Dogan and Rafi, Founding Members of Clave

Ivo, Founder of Ambire

Itmar, Founder of Argent

Kurt Larsen and Konrad, Co-founders of Rhinestone

Pengyu Wang and Peter Pan, Co-founders of Particle Network

OKX Wallet Team

David Kim, Engineering Lead at Trust Wallet

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。