This article is original by the SevenX research team and is for communication and learning purposes only and does not constitute any investment reference. If you need to cite, please indicate the source.
Original link: https://mirror.xyz/sevenxventures.eth/3sYkMimEKqzQbme8-KszvSrKGj4uPxBLyJM9ncXxgcU
Author: Rui, @Ruisnakes
Table of contents
Encryption user experience is bad? Its key management that sucks!
Key Management: Responsibility, Storage and Access
Analysis of existing products: MetaMask, Trust Wallet, Privy and Particle
New solution:
- Key layers: WebAuthn, Secure Enclave (Secure Enclave) and Passkey (Passkey)
- Account layer: smart contract account (SCA), external account (EOA)
- Signature layer: protocol r 1 precompilation, third-party services, Solidity and zero-knowledge validators
Case Study: (Key) + (Account)
- Clave wallet: (Secure EnclaveWebAuthn) + (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 node + Passkey) + (EOA/SCA)
*Please note that the above cases may change and improve quickly
Outlook
TL;DR
Private keys are key to signing transactions on Ethereum, but even when managed in a human-readable form like a mnemonic phrase (also known as a seed phrase), managing a users private keys can be a nightmare. And we know that turning blockchain into a complex game has never been our intention.
To ensure transaction security, authorized users must be authenticated. As internet security and user experience have evolved, we have evolved from password verification to biometrics such as facial recognition and fingerprints. WebAuthn is a key milestone in this progress. This article will focus on three terms:
WebAuthn：This is a web authentication standard that uses public key-based credentials, usually created by an external authenticator. Secure user authentication is also possible without the need for a password.
Secure Enclave：A hardware-based security enclave within a computing device designed to protect sensitive data. Different versions of Secure Enclave are available for iOS, Android, and Windows devices. Using WebAuthn, it can act as an external authenticator, bringing hardware-level security, but since the private key is bound locally, this can make cross-device operation difficult.
Passkey：WebAuthn is applied at the operating system level, and various device and system providers have their own custom rules. For example,Apple PasskeySync across devices using keys stored in iCloud Keychain. However, this method is usually only applied to a specific platform or system and cannot be implemented across systems (Apple-Android).
As mentioned above, WebAuthn deployment is consistent with our goals for everyday blockchain users, which is to achieve advanced anti-phishing security and a user-friendly experience. The following are proposals for integrating WebAuthn implementation into the blockchain:
Key layer:Users can authenticate using silky-smooth methods like facial recognition or fingerprints. Under the hood, its a hardware-based security processor (such as a Secure Enclave) or a cloud service (such as iCloud and Google Cloud) that handles key management. I will discuss cross-device and cross-platform issues in depth later.
Account level:Smart Contract Accounts (SCA) can assign arbitrary signers (such as SE and Passkey) and threshold mechanisms. Additionally, its modular design enhances flexibility and upgradeability. For example, a smart contract account can dynamically adjust its signature requirements based on factors such as transaction volume, time, or IP address. On the other hand, traditional external accounts (EOA) can be extended with multi-party computation (MPC) services. This combination provides better interoperability and cost-effectiveness compared to smart contract accounts, but does not have the advantages of smart contract accounts. The advanced features provided, especially key rotation, can be more challenging.
Signature layer:Ethereum natively supports the k 1 curve, but WebAuthns signature verification incurs a higher cost because it uses the r 1 curve to generate keys. Therefore, Layer 2 solutions such as zkSync are planned to use nativeEIP-7212 Precompilation of r 1 curves. In addition, there are third-party services, Solidity validators, zero-knowledge (ZK) validators, and distributed key management systems that can facilitate r1-curve signing in a more cost-effective manner.
*Disclaimer:
Technological progress does not guarantee success in the market; not all devices and platforms have adopted Passkey; using smart contract accounts may be more expensive than external accounts; and the solutions proposed will continue to evolve with technological progress.
Encryption user experience is bad? Its key management that sucks!
In the field of blockchain, the real control of blockchain assets does not lie in the hands of users or wallet providers, but in the private keys. This key determines the success or failure of transaction execution on Ethereum. To understand this better, let’s take an external account as an example:
Key generation: A random number selected from the secp 256 k 1 elliptic curve as the private key. This private key is then multiplied by predefined points on the curve to generate the public key. Ethereum addresses are derived from the last 20 bytes of a hash of a public key. Usually, we will use a mnemonic phrase to convert the private key into a human-readable word as a backup to ultimately generate the private key and public key.
Sign transaction: Use the private key to sign a transaction that contains details such as nonce (serial number), amount, gas price, and receiving address. This process involves the Elliptic Curve Digital Signature Algorithm (ECDSA), which uses elliptic curve cryptography and adopts the secp 256 k 1 curve to generate a signature consisting of (r, s, v) values, and then combines the signature and The original transaction is broadcast to the network.
Verifying transactions: Once a transaction reaches an Ethereum node, it will be verified in the node’s mempool. To verify the signer, the node obtains the senders public key using a signed and hashed transaction and confirms the authenticity of the transaction by matching the extracted address with the senders address.
As mentioned above, the private key is an important entity on the chain. Initially, Ethereum accounts, i.e. external accounts, relied entirely on a single private key, which presented significant risks since losing the private key meant losing access to the account.
Many people may think that Account Abstraction (AA) is the ultimate solution to user experience problems, but I would say that is not necessarily the case. Account abstraction turns the validity rules on Ethereum into programmable rules, and smart contract accounts allow them to be implemented. Account abstraction is very powerful. It can send multiple transactions in parallel (abstract nonce), gas sponsorship, and supports the use of ERC 20 to pay gas (abstract gas). There is also a function more related to the topic of this article - account abstraction can break the fixed signature verification. (Abstract ECDSA signature).Unlike external accounts, smart contract accounts can be assigned arbitrary signers and signing mechanisms, such as multisigs or scoped keys (session keys). However, despite the increased flexibility and scalability of account abstractions, keys are still required for transaction signatures.
Even if the private key is converted into a 12-word mnemonic phrase, managing the private key can still be a challenge, with the risk of losing it or being exposed to phishing attacks. Users must choose between complex decentralized solutions and centralized services, neither of which is ideal.
Why is the encryption experience terrible? A lot of this is because of poor key management. Users always need to make a trade-off between experience, security and decentralization when managing keys. This article explores potential best solutions for managing keys.
key management
There is never a one-size-fits-all solution, and the best way to keep keys needs to be customized for specific user scenarios and influenced by many factors, such as user type (institution or individual), amount of capital, frequency of transactions, type of interaction, etc.
To clarify upfront, I won’t be using the popular terms “self-hosted, semi-managed, and fully managed” that are currently in vogue. In my opinion, true self-custody means not relying on other parties and signing transactions independently, even if some solutions are not considered hosting in the traditional sense (such as being stored in a trusted execution environment of decentralized nodes), nor Considered non-custodial. Judging whether a solution is good or bad based solely on hosting type is too simplistic and fails to take into account the differences in suitability of these solutions. To evaluate a key management approach in more detail, I recommend analyzing it along three different dimensions.
responsibility
Whether to divide the responsibility for key management among different responsible parties.
Because of the challenges individual users often face when managing keys, assigning key management responsibilities is a natural risk mitigation strategy. Such methods include the use of multiple keys for collaborative signing, as is the case with multi-sig systems, and the splitting of private keys into multiple parts via secret sharing schemes (SSS) or multi-party computation (MPC).
Multi-sig: Multiple complete private keys are required to generate transaction signatures. This approach requires on-chain communication between different signers, has higher transaction fees, and affects privacy because the number of signers is visible on-chain.
Secret Sharing Scheme (SSS): Generate a private key in a single location, then divide this key into multiple parts and distribute them to different parties. Each party must reconstruct the complete private key to sign the transaction. However, this ad hoc reconstruction may introduce vulnerabilities.
MPC-TSS (Threshold Signature Scheme): As an implementation of multi-party computation, this encryption method enables multiple parties to perform computations while keeping their inputs jointly private. Each party independently creates a key shard and can sign transactions without physically meeting. Because it is operated off-chain, the cost of this method is low, and there is no single point of failure risk like the secret sharing scheme.
storage
Storing keys or key fragments is subject to security, accessibility, cost and decentralization factors.
Centralized cloud services, such as AWS, iCloud and other servers. This approach facilitates frequent transactions but is more susceptible to scrutiny.
Local computer/mobile device: The key is stored in the browsers secure storage.
Paper wallet: Print out the private key or QR code.
Trusted Execution Environment (TEE): The Trusted Execution Environment provides a secure area within the main processor that executes or stores 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 keep sensitive user data safe even when the application processor core is compromised.
Hardware wallet: e.g.LedgerandTrezorand other physical devices designed to securely store private keys.
Hardware Security Module (HSM): A hardware security module is a hardware device specifically used for secure key management and encryption operations. It is typically used in enterprise environments and provides high-level security functions.
access
How to authenticate a user to access stored keys
Access to stored keys requires authentication. This requires verifying that the individual attempting access is indeed authorized to access the key. Looking back, access methods can be categorized as follows:
What you know: Passwords, PINs, answers to security questions, or specific graphics.
What you have: Includes smart cards, hardware tokens (time-based one-time passwords), or digital factors like social account verification and text message codes sent to your phone.
Who you are: The users unique physical characteristics, such as fingerprints, facial recognition (such as Apples Face ID or Windows Hello), voice recognition, or iris/retina scans.
On these foundations, two-factor authentication (2FA) and multi-factor authentication (MFA) combine at least two factors, such as text messages with push notifications, to strengthen the security of user accounts.
Analysis of existing products
MetaMaskAllows users to use a password to access keys stored in local browser storage.
Trust WalletAllows users to access keys stored in the users local browser storage using a password or faceID, with the option of backing up private keys using a cloud service.
PrivyAllows users to use multiple social login methods such as email, with a secret sharing scheme that splits the key into three parts:
Device fragmentation: browser-iFrame, mobile-Secure Enclave.
Auth authentication shard: stored by Privy, linked to Privy ID.
Recovery recovery fragment: user password or stored encrypted by Privy inHardware Security Module (HSM)middle.
ParticleAllow users to adopt social login, using MPC-TSS, splitting the key into two parts:
Device Sharding: Browser-iFrame
Server key section: Particle’s server
new solution
Key layers: WebAuthn, Secure Enclave, and Passkey
The above existing solutions have played a key role in attracting users to Web3. However, challenges come with it: Passwords can be forgotten or become the target of phishing attacks, and 2FA, while more secure, can still be cumbersome to use because it involves multiple steps. In addition, not everyone is willing to entrust a third party with key management, and when some services prevent users from accessing keys, users still have to rely on the availability and validity of the system.
This got us thinking if there was a more effective solution – one that would provide near trustlessness, high security and a seamless user experience. The pursuit of this solution leads us to find the optimal Web2 approach. As mentioned at the beginning of this article, there are several terms closely related to this topic, WebAuthn is the authentication standard, and Secure Enclave and Passkey are deployments or components related to the standard.
WebAuthn
WebAuthn specifies an interface for user authentication for web-based applications. Users can log into Internet accounts using external authenticators instead of passwords. The authenticator can be a roaming authenticator (such as Yubikey, Titan key) or a platform authenticator (such as the built-in keychain on Apple devices), etc.
The technology behind WebAuthn was originally developed by the FIDO (Fast IDentity Online) alliance. In March 2019, W3C officially announced WebAuthn as a Web standard. With the development of its standardization, major browsers such as Google Chrome, Mozilla Firefox, Microsoft Edge and Apple Safari have adopted WebAuthn, significantly expanding the application of WebAuthn. Scope and availability. Now availableSupport for many advanced devices。
Advantages of WebAuthn:
Better security:No more reliance on passwords, reducing the risk of phishing, brute force and replay attacks.
Improve user experience:Provides simpler, faster login, often with just one click or biometric verification.
privacy protection:No shared secrets are transmitted during the authentication process, and no personally identifiable information is received by individual websites.
Scalability and standardization:As a web standard, WebAuthn ensures consistency and interoperability across different browsers and platforms.
Device-based WebAuthn, such as Secure Enclave
Today, we can use hardware processors as authenticators, such as Secure Enclave for Apple devices, Trustzone for Android devices, and Strongbox for Google Pixel.
Key generation: usepublic key encryption, generate a key pair according to the WebAuthn standard, usually using the P-256 r 1 curve. The public key is sent to the server, but the private key never leaves the Secure Enclave. The user never handles the plaintext key, thus ensuring the security of the private key.
Key Storage: Private keys are securely stored on the deviceSecure EnclaveInternally, this hardened subsystem is isolated from the main processor. It protects sensitive data so that even if the main system is compromised, the original key material cannot be accessed. The barrier to cracking the Secure Enclave is very high, so the most sensitive data types, such as Apple Pay and FaceID data, are stored here. Here you can view theSecure EnclaveAn in-depth explanation of how it works.
Authentication: Users use facial recognition or fingerprints to gain access, Secure Enclave uses private keys to sign server-side challenges, and the server uses public keys for verification.
Advantages of device-based WebAuthn:
Hardware-like security:Secure Enclave, a standalone hardware-based key manager, increases security.
Fight phishing attacks:Do not enter any information on a potentially compromised device or website.
Convenient experience:Provide 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, private keys cannot be exported or retrieved, and cross-device operations are not possible.
Cloud-based WebAuthn, Passkey
To solve the challenge of cross-device functionality, the tech giant introduced cloud-based WebAuthn deployments, Passkey is made famous by Apple.
Take Apple’s Passkey as an example:
Key generation: The users macOS, iOS, or iPadOS device acts as an authenticator, generating public and private keys when the user creates an account. The public key is then sent to the server, while the private key is stored in the devices iCloud Keychain. iCloud Keychain data is encrypted with a hardware-bound key pair and stored in the hardware security module. Apple cannot access the key pair.
Sync across devices: This process is the same as accessing iCloud. Authenticate your iCloud account, receive an SMS verification code, and enter the password for one of your devices.
Advantages of cloud-based WebAuthn:
Across devices:Passkey is designed to be user-friendly and accessible on all the devices they use regularly. But it’s currently limited to Apple devices. This approach is more challenging for Android devices because of the wide variety of Android versions and hardware.
Prevent phishing attacks:Same as above.
Convenient experience:Same as above.
Disadvantages of cloud-based Passkey:
Depend on cloud services:Compared to device-based WebAuthn, cloud-based Passkey moves the security layer from the Secure Enclaves hardware to iCloud Keychain, which some might consider hosted on a cloud service. Some key points to consider include whether a users iCloud AppleID account has been compromised; while iCloud Keychain uses end-to-end encryption to protect data, operational errors or vulnerabilities pose risks.
Platform restrictions:For example, using iCloud-based passwords on Android devices is extremely challenging. Additionally, unlike traditional approaches, Apple and Google do not send device-specific assertions. This means that there is currently no way to verify the type of device that generated the key, raising questions about the reliability of the key and its associated metadata.
Account layer: smart contract accounts and external accounts
So far, we can see that keeping the hardware secure while addressing cross-device and cross-platform compatibility is a big challenge. Just as important are social recovery options, such as adding multiple guardians for enhanced security. In this case, blockchain can show us a way.
Please note: When we try to deploy Web2s WebAuthn to Web3, one obvious difference is that Web2 only needs to prove ownership, while Web3 also needs to authorize the transaction as well. If only owning the Passkey, the developer has no control over the signed message, which is usually generic, such as sign in. This can lead to potential front-end manipulation issues, where users blindly sign messages - a seemingly trivial but critical issue.
The smart contract account itself is a smart contract. As an entity on the chain, the smart contract account can designate any signer. This flexibility allows users to configure settings for a variety of devices and platforms, such as Android phones, Macbooks, and iPhones as signers. In addition, the modular smart contract account supports upgrades, can exchange new signers, and can change the signature threshold from 2/3 to more complex configurations.
Imagine a wallet that can flexibly adjust its security needs based on the situation: this wallet supports single signer authentication when the user is on a familiar local IP address, but requires multiple signer authentication for transactions from unknown IP addresses or above a certain value. Signed by. With modularity and programmability, there are only innovations that we cannot imagine and cannot achieve. Many smart contract account service providers are actively building in this area, including Safe,Zerodev、Biconomy、Etherspots, Rhinestone et al. I would also like to thank people such asStackup、Plimico, infrastructure like Alchemy makes this possible.
please check meprevious studies, to get more comprehensive background information about smart contract accounts.
Smart contract accounts enable social recovery and cross-device/platform compatibility through multi-party computing services. Although smart contract accounts have fixed signers, multi-party computation providers can split the key into multiple parts for enhanced security and flexibility. This approach does not have the programmable and upgradeable features of smart contract accounts, such as timelock recovery and easy deactivation of keys. However, MPC is not restricted to a specific blockchain, so it has excellent cross-chain capabilities and is more cost-effective than smart contract accounts. Well-known multi-party computation providers include Particle Network,Privy、web3 Auth、OKX Wallet、Binance Walletwait.
Signature layer: R 1 supported
Lets take a step back to understand: on Ethereum, the private key is a random number chosen from the k 1 curve, and the signing process also utilizes this curve.
However, key pairs generated according to the WebAuthn standard use the r 1 curve. Therefore, the cost of verifying an r 1 signature on Ethereum is approximately three times that of a k 1 signature. Here are the solutions to this problem:
Thanks to Dogan for his contribution, check out his research for more in-depth knowledge.
Protocol solution:
solution:EIP 7212 , precompiled with support for the secp 256 r 1 curve, provided byClaveTeam proposal.
Evaluation: This proposal creates a precompiled contract that performs signature verification in a secp 256 r 1 elliptic curve given a message hash, the r and s of the signature, and the x,y coordinate parameters of the public key. Therefore, any EVM chain (mainly Ethereum’s Rollups) can easily integrate this precompiled contract. Protocol precompilation is probably the most gas efficient solution so far.
application:zkSync
Third party services:
Solution: Turnkey
Assessment: Turnkey TEE ensures that the private key is only accessible by the user via their Passkey, Turnkey never has access to the private key, however this is still required for the service to be valid.
Implementation: Goldfinch
Solidity Verifier solution:
Solution: FCLs Solidity Verifier, FCL with Precomputed Solidity Verifier, Daimos P 256 Verifier
accomplish:Clave，Obvious Wallet
Zero-knowledge (ZK) validator:
Evaluation: This approach uses zero-knowledge proofs to verify computations outside of the Ethereum Virtual Machine (EVM), reducing on-chain computing costs.
accomplish:Bonfire Wallet (Risc Zero)，Know Nothing Labs (Axiom)
These solutions can all enable cheaper and feasible r 1 signature verification in the Ethereum ecosystem. The following areDoganevaluation of.
WebAuthn New Case Study
*Please note that as of December 2023, most of these solutions are in their 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: https://getclave.io/
Account: smart contract account
Chain: ZkSync
Transaction process:
Key Creation: The user undergoes biometric verification, such as fingerprint or facial recognition, and a key pair is generated within the Secure Enclave that can never be compromised.
Key Signing: The application receives the required transaction message and forwards the signature request to the Secure Enclave, the user performs biometric verification to approve the signature, and the Secure Enclave signs the message using the key and then broadcasts it to the blockchain nodes.
Additional features: Smart contract accounts support many powerful features. The first is gas sponsorship. Using Paymaster, dApps or advertisers can pay for gas for users, making the transaction process smoother, and also allowing users to pay for gas using ERC 20 tokens instead of only Ethereum or native tokens. In addition, users can use session keys to conduct signature-free transactions over a period of time.
Recovery mechanism:
The recovery process is performed by Claves smart contract on zkSync, and users can cancel the recovery within a 48-hour lock period to prevent unauthorized malicious activity.
Cloud backup: When the user chooses cloud backup, an external account will be created. The private key of the external account is stored in iCloud or Google Drive. The user can use the private key stored in the cloud to access his account from different devices, and can also delete or delete it at any time. Overwrite this backup section.
Social recovery: Users can specify their family or friends Clave addresses as backups, and if M out of N guardians confirm the recovery and do not cancel it, execution resumes after a 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, will soon fully support Ethereum Virtual Machine Layer 2
Transaction process:
Key Creation: The user provides biometric verification such as fingerprint or facial recognition, and the operating system generates the Passkey, which is backed up using a cloud service. Users can add multiple Passkeys across devices and platforms.
Add a Guardian (optional): Users can specify different Ethereum Virtual Machine external account addresses as guardians and set account recovery thresholds.
Account generation: With counterfactual deployment, users do not need to pay anything until they make their first transaction.
Recovery mechanism:
Passkey: Use any defined Passkey to log in to the wallet on any device.
Guardian recovery: Designated guardians can rotate wallets based on thresholds and can later set time locks to prevent malicious behavior.
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
Chains: 30+ chains
Key: MPC-TSS, 2/3
Account: 4337 smart contract account
Transaction process:
Key Creation: By creating a wallet, OKX separates a single private key into three separate parts. One part is stored on OKX servers, one part is stored in local storage on the users device, and one part is generated by the device, encrypted, and can be backed up to the devices preferred cloud service, such as Google Cloud, iCloud, and Huawei Cloud.
Key Signing: OKX uses MPC-TSS technology, which allows 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 come into contact with each other.
Recovery mechanism:
2/3 mechanism: When the user logs out, the device is unavailable, or one of the keys on the device is leaked, the user can use a new device to log in to the OKX wallet (obtain the key stored on the server) and obtain the key part stored by the cloud service, Restore the wallet using these two part keys and 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, usually 2/3
Account: Any account such as external account, 4337 smart contract account or general smart contract account
Transaction process:
Key Creation: By creating a wallet, three key parts are generated. One section is for social login, where users can enter their email and a decentralized network node stores each users key; one section is for keys stored in the local storage of the users device; and one section is provided by the local computer Generated and backed up by the users preferred cloud service.
Key Signing: The Web3 Auth MPC-TSS architecture ensures that a users key is always available, and even with threshold signing, the key is never reconstructed or stored in a single location.
Recovery mechanism:
Threshold recovery: When the user logs out, the device is unavailable, or a key on the device is leaked, the user can use the social login method to log in to the WebAuthn account and obtain the key part of the cloud storage, and use the keys of these two parts to restore the wallet .
Lit Protocol (MPC-TSS + Decentralized Node + Passkey) + (External Account/Smart Contract Account)
Basic Information:
Demo: https://lit-pkp-auth-demo.vercel.app/
Chains: Most EVM, Cosmos, Solana.
Account: MPC-TSS, 2/3 mechanism, can be applied to both smart contract accounts and external accounts.
Transaction process:
Key creation: When a user wants to create a wallet, he first selects an authentication method (supports Passkey, oAuth social login), then sends a request to the relayer to create a key pair and stores the authentication logic into the smart contract . Each key pair is generated jointly by Lit nodes through the Distributed Key Generation (DKG) process. As a decentralized network, TEE runs 30 Lit nodes internally, each node holds a part of the key, but the private key will never completely exist in TEE.
Key signature: After receiving the request, Lit nodes independently verify or reject the request based on the specified authentication method and use MPC-TSS technology, 1. Generate a signature when the collection exceeds the threshold (20 confirmations out of 30 nodes), and Composed by the client to satisfy the request.
Recovery mechanism:
2/3 mechanism: Use the authentication method stored in the smart contract to access the account, Lit nodes verify the request, and if more than 2/3 of the nodes confirm, the request will proceed.
Outlook
Powered by 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 to pursue true security. All efforts are directed toward the same goal: cryptography ready to be used in users’ daily lives.
It’s easy to get stuck in an ideal technological dream, but we must ask ourselves: What kind of experience are we pursuing? We envision a world where cryptocurrencies should be intuitive and easy to understand rather than intimidating technical jargon; a world where users can jump down rabbit holes without hesitation and without breaking a sweat. .
Imagine there is a user named Rui: she discovers a great dApp that makes it easy to register using facial recognition or fingerprints and set up backups or guardians. She can easily execute the transaction using the dApp, possibly for a small ERC 20 fee, or maybe even no fees at all. Afterwards, she can customize wallet settings, such as activating time locks for automated transactions, adding another device as a backup signer, or modifying her list of guardians.
Entrepreneurs are working hard to make this happen. Combining WebAuthn and Passkey, weve enhanced private key management to make it both secure and convenient. On this basis, the smart contract account as an entity opens up the field of personalized security and functionality. As for gas? With Paymaster, providers can create a “vault” for swap transactions and even allow advertisers to pay users so gas is no longer a burden. Central to this evolution, particularly for the Ethereum mainnet and its Layer 2 equivalent, is ERC 4337. ERC 4337 introduces an alternative mempool that separates smart contract account transactions from external accounts without requiring major modifications to the protocol. On the other hand, some Layer 2 networks even natively adopt smart contract accounts and integrate them seamlessly into the system.
It takes a huge amount of effort to make everything simple. We also face many challenges, such as reducing the deployment, verification and execution costs of smart contract accounts; standardizing interfaces to enhance account interoperability; synchronizing account status across chains, etc. 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 vision.
If you are interested in this article, please check out my other articles for more comprehensive background information:
04/ Account:Modular smart contract account architecture and challenges
03/ Keys (this article): WebAuthn and Passkey, key management for daily encryption users
02/ Infrastructure:The evolution of Ethereum accounts brought about by ERC 4337
