While the road to the mass adoption of Web3 is far off, it’s still picking up speed across different industries, with more and more users onboarding in the world of crypto, gaming, collectibles, social media, and more. Like any big technological change, adoption will be faced with skepticism, resistance, and confusion. That is until it becomes the norm.
With the rise in popularity of NFTs, blockchain gaming, and cryptocurrencies, Web3 is becoming more tangible but it’s yet to be mainstream and part of its challenges is its current onboarding process. Right now, it’s complicated. Users have to not only understand but navigate a completely new set of tools and technologies, like wallets, private keys, gas fees, and smart contracts. Even though it’s easy once it’s described in layman’s terms, each and every one of those concepts can be intimidating, especially for nontechnical users. There’s also fragmentation across different Web3 networks and platforms with no standardization which leads to difficulties in switching between different dApps and blockchains.
And then there’s the actual user experience — right now, there’s a steep learning curve even for those familiar with the tech. To participate in anything Web3 can require a lot of onboarding from setting up an app, and then to actually using it. You might need to install different software, create a new account and navigate unfamiliar interfaces while understanding a whole new set of terminology and experiences. Wallets, while being the gateway into Web3, can be non-intuitive at best, and confusing at worst (the 24-word private keys, learning how to securely store them and back them up, learning about gas, transaction fees, approvals, etc).The process of setting up a wallet can be very frustrating to the point it can make users want to abandon it and give up (for now) Web3 activities. But, to access dApps and thus Web3, you need a wallet and there are currently no easy ways of getting one. This problem is one of the bigger focuses for Web3 and solving the onboarding blockers. So how to get around the need for a wallet while making the user experience more fluid? One way is to dig into account abstraction and biometrics.
But first, what are wallets? It’s essentially your identity on the blockchain — and its private key a secret that no one else should know or have access to. When it’s created, it generates a long series of numbers that equates to your account number, your signature. To do anything on the blockchain, whether it’s a financial transaction or even to say “hello!” to someone, you need that number as your signature. In cryptography, it allows you to be identified as really you. It’s secure and hard to hack but lose that secret number and you lose access to your entire wallet.
Right now, managing a wallet is complicated and the user experience is bad. There can be many steps to a transaction with different windows popping up and you often need to download a third-party app (like Metamask) to help you interact with your wallet. While it helps, it also makes you more vulnerable to attacks.
The objective of Cometh’s P256 hack was to create a wallet for a user without them knowing it was created, and without any steps, a traditional user isn’t familiar with. To achieve this result, P256 uses a well-known biometric standard called WebAuthn.
WebAuthn is the current Web2 sign-on standard used by the majority of online services that implemented passwordless sign-ons (such as your bank app). This standard uses public key cryptography to register and authenticate users, and its security is achieved via biometrics and storage processes. It operates at a systemic level such as TouchID/FaceID on iOS, Hello for Windows, or FIDO on Android. It’s revolutionized the way we interact online, removing the need to remember all the different passwords and it can become way more secure: it’s much harder to hack someone’s face or fingerprint than it is a password.
With P256, anytime you need to sign a transaction, you’ll just have to enter your biometrics and it’s done! It’s an experience that is familiar, almost second nature to most online users now when dealing with sensitive information or transactions. It comes with a caveat though: with Web3 wallets (such as Metamask and others), you see exactly what you’re about to sign. With P256 (similar to any web2 transactions) you need to trust the website you’re on.
P256 also offers some security versatility about where your WebAuthn private key (think biometric key) is secured. In our current demonstration, it is stored in a browser, but it can be stored in a phone-secured enclave, or in a hardware wallet. This option also comes with the burden (and potential setback) of forcing users to buy a Ledger in the first place, all in the name of increased security. But baby steps — the primary objective (for now) remains the user experience of Web3 and the different ways we can improve it.
Account abstraction is to web3 what WebAuthn has been to web2: a revolution in the sign-in process. Right now, there are two standard accounts on Ethereum: contract accounts and externally owned accounts (EOA). Any on-chain transactions are initiated and paid for by EOA. And to use it, it’s via your private key — the same key you use for any signatures (or transactions) on the Ethereum blockchain. So while being vulnerable to loss, it’s also vulnerable to attacks. Account abstraction here aims to unify both types of accounts and allows for more flexibility and programmability. This means you can transform accounts into smart contracts with their very own logic to define what a valid transaction is and is not. It also means you can set the security features while improving the overall user experience.
And here lies the magic: While WebAuthn is primarily designed to secure Web2 authentication, it can be extended to support a different sign-on logic. And when coupled with the principle of account abstraction, it can be used for signing contracts on Web3. The missing ingredient was P256.
For its signing algorithm, Ethereum currently uses Elliptical Curve cryptography. Several different curves exist, defined by different mathematical equations, but Ethereum itself uses secp256k1 for its own algorithm called ECDSA. Used also on Bitcoin, it generates and verifies all digital signatures. Whenever a transaction is made, users utilize their private keys to sign using the ECDSA algorithm. The problem lies with the fact that this specific curve, while compatible with WebAuthn, has never been implemented in its standard.
P256 uses the secp256r1 elliptical curve, a widely accepted cryptographic standard that can be applied on Ethereum to create secure authentication and signing for transactions/smart contracts. .The WebAuthn framework can be extended to support signing with keypairs generated on authenticators without requiring custom clients for end users. The signature is verified on-chain by a smart contract. This architecture drastically simplifies the user experience of creating a wallet. The user’s private key is securely generated and stored natively in the user’s device, with nothing else than his biometrics. This means the end of the 24 words passphrase hassle.
Users can securely sign transactions using P256 and WebAuthn without the need for customized apps or additional software.
And that’s what we did with our prototype/demo “P256 on EVM”.
Our P256 prototype was designed to show how WebAuthn and Ethereum Account Abstraction can transform the way we verify signatures. For the demo, we demonstrated the process of registering a user, deploying a wallet, and finally, minting an NFT — all with your fingertip. This simplified 1–2–3 step allows users to have a more seamless onboarding to the blockchain without all the current blockers affecting the Web3 user experience with a web2 standard: biometric verification process.
What we initially wanted to do was verify signatures using only your fingertip. For the first part, we used WebAuthn to connect with the private key in your phone/computer to verify it off-chain. Once verified, we wanted to take it on-chain. We verified off-chain because doing so on Ethereum (on-chain) could quickly become extremely expensive in fees. Gas fees, what you pay to execute transactions, is dependent on the current demand for gas and cannot be manipulated. It’s the law of supply and demand: the greater the demand, the greater the price.To verify the signature, we need to use this equation:
R’ = (h * s1) * G + (r * s1) * pubKey(for context, check out the ECDSA signature algorithm here)
This encrypted public key cryptography equation allows for more secure online interactions — and alongside account abstraction enables more secure smart contracts. The problem lies in the fact that the cost of verifying this equation is extremely high and if applied to mass users to verify all on-chain transactions, no one could afford it — it requires a significant amount of computational power to calculate.
What we wanted to do was find a way to optimize the algorithm to reduce gas prices and a way to verify the ECC equation (R’ = (h * s1) * G + (r * s1) * pubKey) without it costing a lot in fees. The first thing we did was the Shamir Trick.
Shamir Trick
In the context of the ECDSA (elliptical curve digital signature algorithm) verification, the Shamir Trick aims to optimize the calculation of the ECC equation in the form of
u*G + v * Q.
If we take the ECC equation (as a reminder — R’ = (h * s1) * G + (r * s1) * pubKey),
U = h*s1V = r*s1Q = pubkey
The (assumedly) more logical way to calculate this equation is also the more naive way: calculating the parts separately and then adding them together. However, using the Shamir Trick allows you to calculate both u*G and v*Q at the same time by interleaving the calculations of 𝑢⋅𝐺 and 𝑣⋅𝑄. By examining binary representations of “u” and “v” bit by bit, and based on their values, it decides whether to add 𝐺, 𝑄, or 𝐺 + 𝑄 to a running total, thereby reducing the total number of point additions required (more on that here).
Whether the math behind it is comprehensible, or it seems to be a work of magic, the important part to remember is that by doing two calculations at once, you decrease computing power. And in terms of resources, by reducing the computational exertion, you can reduce gas fees.
To further optimize these expensive calculations, the Shamir Trick is followed up with the Windowed Method.
Windowed Method
The windowed method is a way to make these calculations more efficient. It pre-computes parts of the calculations related to the user’s public key and saves them on the blockchain. For each user, it generates two contracts: a smart contract and a generated table. The smart contract wallet is what we already understand it to be — a personalized contract that controls someone’s interactions (transactions and otherwise) with the blockchain.
Deploying a smart contract wallet in itself doesn’t cost a lot of gas because it uses a “factory pattern” (link to factory pattern) — a way to create multiple instances of a class without specifying the exact class type. The generated table, on the other hand, is an additional contract that stores pre-computed values related to the user’s public key. The initial cost that is spent to deploy this table is recovered by the gas saved on each transaction after only two transactions from the smart contract wallet.
By having the pre-computed values available in the table, the ECC calculations can be done more efficiently. It helps with the two EC points multiplications of the equation:
(h * s1) * G and (r * s1) * pubKey
since you can directly use the values in the table rather than having to calculate them from scratch, which in turn saves a lot of resources and time. It streamlines the verification process by deploying the results directly on-chain.
So in the end, what we created in our P256 demo was a way to show how it’s possible to deploy a smart contract wallet on Ethereum (or any EVM blockchain) by using what the majority of people already have on their phones or computers, all thanks to an elliptical curve natively supported in all smartphones and almost all web browsers.
Once a user is onboarded with account abstraction, they remain in total control. There is no sharded key scheme or Multi-party computation bypassing the key custody: the key to activate the smart contract sits in a user’s hardware. As the user remains in total control of the smart contract wallet, it allows for the addition and deletion of control keys through traditional blockchain wallets like Ledger, Tresor, Metamask, etc.
While it requires a degree of trust with a website asking you to sign, it’s still technically safer than using an email address, a method susceptible to hacks and data leaks as we’ve seen time and time again. It deploys a smart contract for a client’s key but in-between, there’s no other service, just your biometrics traits already available to you.
What we also achieved is something that is user-friendly, especially for the non-Web3 initiated and that is relatively inexpensive. These are critical points in trying to bring mass adoption of blockchain-based applications. In our experience with our blockchain game Cometh Battle, acquiring new players can be really difficult. While our game is known, there aren’t that many people in Web3, and that’s a reality facing many blockchain projects. The next step is to try onboard players from Web2 but due to lack of incentives and complicated wallet processes, the turnaround remains low, even when using Twitter, TikTok, Facebook, or whatever to promote it. And especially for gamers, the normal Web2 method works and so does the adage “if it ain’t broke, don’t fix it”. The majority of people won’t make an effort to do a bunch of different steps to reach a goal especially when there’s no apparent value. But this isn’t to say we’re trying to submerge Web3 into Web2, but this can open doors to opportunities of onboarding and education. It doesn’t solve everything, and there’s still a way to go.
Our current approach, our P256 demo, only really solves one aspect of the Web3 onboarding problematic: user experience. But increased user experience comes with its pitfalls, notably security. Ledger’s Nicolas Bacca calls this the Triangle of Zooko. When he came by our HQ in Paris to participate in our Just Build Meetup, he demonstrated the trilemma with these 3 factors:
Extract from Ledger’s Nicolas Bacca’s presentation of “The Triangle of Zookoo”
In a perfect world, we’d have all three: something decentralized with good security and a good UX. But right now, either we have something decentralized with good UX (internet), and with smart wallets, we have something that is secured and decentralized.
Here is a more detailed look:
Right now, there’s a sort of tradeoff between user experience and security, having users choose which they prefer. Nicolas breaks it down and goes in-depth but the way to have it all is account abstraction.
P256 also doesn’t solve how to store your key. When you use a platform like Metamask to manage your wallet, it’s on your PC. You’re then asked to save 24 words to back up your key. However, you lose your 24 words and your PC, you lose your wallet. Our solution allows you that choice. If you want to store it on your Ledger, you can. If you want to connect with your SecureCloud, you can. What we can’t do is help with how you save it, how you make sure it’s safe, and how it’s accessible at any moment. If you lose your computer, your Ledger, your iCloud password, etc, we can’t help you recover it. And we can’t store it for you — doing so removes the aspect of decentralization, not to mention (again) vulnerabilities to leaks and hacks. But what we’ve developed (and are developing) is allowing us to get one step closer to changing the way we interact on Web3.
User experience remains a central piece of the puzzle on how to bring about mass adoption of Web3. Account abstraction, both as a concept and a methodology will help to bring about this change by relying on standards already prevalent online, notably that of biometric sign-on.
Right now, we’ve developped an onboarding SDK based on our P256 demo using account abstraction, where the signer and the account are separate — the signer can be any entity and the SDK can link to any signer. This smart wallet, Cometh Connect will let you connect whichever way you choose — E-mail, Facebook, Google, or your fingerprint — and it’ll be purely decentralized. We could have created public keys and managed them, but we don’t want that responsibility or add to a decrease in security for users. Going even further, app creators implementing our SDK will be able to sponsor their users’ gas fees, allowing for a truly seamless web2 experience for users. Of course, the cost of this can be recuperated by the owners via their own monetization strategies that are global to the app itself (ex: including it in the app’s monthly fee, etc). So while the user is still (indirectly) interacting with the blockchain (wallet creation, being subject to gas prices), all this remains behind the scenes, something you can’t achieve with a classic wallet.For devs, with about 5 lines of code, you’ll be able to add this onboarding solution easily to your product. We’re currently implementing it into our game Cosmik Battle to test it out and then we’ll work on the next steps. Optimizing our P256 solution really remains a solid choice in offering users an alternative to current blockchain onboarding standards in the hope of helping push forward the collective want to bring mass adoption of Web3.
This was written in collaboration with Lakhdar Slaim.
Visit our website to learn more , and follow us on Twitter for news and updates
